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SECTION  1 


INTRODUCTION 


PURPOSE 

A  distributed  database  system  consists  of  shared  data 
distributed  among  geographically-dispersed  computers,  which  are 
linked  by  a  communication  network.  The  system  provides  a  user,  at 
one  computer,  access  to  data  stored  at  another  computer  in  the 
network.  There  are  two  principal  motivations  for  the  use  of 
distributed  database  technology  for  military  command  and  control: 

1.  A  wider  range  of  data  is  available  to  organizational 
components.  This  is  accomplished  either  by  linking 
existing  component  databases,  or  through  overall 
distributed  database  design. 

2.  Through  redundant  dispersed  storage,  critical  data  is 
less  susceptible  to  destruction  or  Iocs. 

The  appropriateness  of  most  any  of  the  choices  among  design 
alternatives  in  a  distributed  database  system  is  governed  by  the 
pattern  of  usage  which  drives  the  system.  The  purpose  of  this  paper 
is  to  describe  the  design,  implementation  and  use  of  a  mathematical 
model,  termed  a  transaction  workload  model,  to  derive  database  usage 
patterns  in  a  tactical  C3  setting. 

The  basic  model  takes  tactical  an'  mission  levels  as  input,  and 
produces  measures  of  da\  ioase  activity  in  terms  of  total  dsiJy 
storage  and  retrieval  operations  for  all  files  and  from  ail  nodes  of 
the  sy.vtem.  Extensions  to  the  basic  model  allow  incorporation  of: 
(1)  time  lines,  so  that  activity  profiles  can  be  derived  for  the 
time  period  and  (2)  file  allocations,  %o  that  communication  traffic 
and  nodal  workloads  can  be  derived. 


SCOPE 


The  task  oi  Project  45t)0,  "Tactical  C3  Distributed  Database 
Systems,"  sponsored  by  Rome  Air  Development  Center/lnformation 
Sciences,  is  the  investigation  of  applications  of  distributed 
database  technology  to  Air  Force  command  and  control  problems.  This 
Drcject  is  focused  on  the  application  of  this  technology  to  support, 
the  force  management  functions  within  the  tactical  air  control 
system.  These  functions  consist  oi  planning,  directing,  monitoring, 
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and  controlling  tactical  air  missions.  Operational  requirements, 
along  with  force  deployments  and  a  24-hour  operational  cycle,  were 
derived  from  a  modified  Korean  training  scenario  (NERA76) .  Detailed 
information  requirements  fo>  a  distributed  database  system 
supporting  the  force  management  functions  indicated  were  derived 
from  TAC  Data  Automation  functional  requirements  (ESDA77).  These 
information  requirements  are  presented  in  (l.AMB78a)  and  (LAMR78b), 

In  order  to  keep  the  investigation  manageable  and  fruitful, 
restrictions  were  placed  on  the  scope  of  the  investigation  in  three 
areas:  (1)  air  mission  types  considered,  (2)  the  amount  of  component 
automation  assumed,  and  (3)  knowledge  required  of  the  user.  These 
restrictions  will  now  be  detailed. 

1.  Air  Missions 


ThQ  types  of  missions  considered  here  are: 

.  counter  air 
.  air  Intel diet ion 
.  close  air  support 
.  air  defense 
.  reconnaissance 

.  combat  air  patrol  and  escort  (referred  to  as  support  missions) 

.  air  refueling  (only  assignment,  not  detailed  planning) 

These  missions  will  be  further  categorized  as  preplanned,  air  alert,, 
ground  alert,  or  immediate  missions.  The  mission  types  omitted  from 
this  study  are: 

tactical  airlift 

.  electronic  warfare 

,  special  operations 

search  and  rescue 

.  air  refueling  (detailed  planning). 
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2.  TADS  Component  Automation 

The  tactical  air  control  system  (TACS)  component  responsible  for 
the  force  management  functions  is  the  tactical  aii  control  center 
(TACC)  with  assistance  from  its  subordinate  components.  Figure  1 
shows  a  typical  organization  of  TACS  components.  Given  our  concept 
of  component  automation,  and  our  restrictions  on  mission  types  and 
functions,  the  components  we  will  concern  ourselves  with  are  those 
enclosed  in  the  shaded  region  of  Figure  1.  Each  of  these  components 
is  assumed  to  be  the  physical  site  of  a  node  of  the  computer 
network. 


IC  INTELLIGENCE  CENTER 

TACC*  TACTICAL  AIR  CONTROL  CENTER 

(ASOC)  (AIR  SUPPORT  OPERATIONS  CENTER) 

LC  LOGISTICS  CENTER 

CRC  CONTROL  AND  REPORTING  CENTER 

PC  PERSONNEL  CENTER 

CRP  COMMAND  REPORTING  POST 


FAOP  FORWARD  AIR  CONTROL  POST 
ASRT  AIR  SUPPORT  RADAR  TEAM 

DASC  DIRECT  AIR  SUPPORT  CENTER 

TACF'  TACTICAL  AIR  CONTROL  PARTY 
ALCE  AIR  LIFT  CONTROL  ELEMENT 
TUOC*  TACTICAL  UNIT  OPERATIONS  CENTER 
(WOC)  (WING  OPERATIONS  CENTER) 


THESE  TERMS  WERE  UNDER  REVISION  AT  THE  TIME  OF  WRITING  AND  MAY  NOT  REFLECT 
CURRENT  TERMINOLOGY  *THE  PARtNTHESIZED  TERMS  ARE  REVISED  DESIGNATIONS, 

BUT  WILL  NOT  BE  USED  IN  THE  TEXT  OF  THIS  PAPER. 

Figure  1.  Typical  Organization  of  Tactical  Air  Control  System 
Components 


3 


3 .  User  Knowledge 

The  user  is  assumed  to  have  detailed  knowledge  of  the  contents 
of  the  database.  The  user  must  know  which  units  of  stored 
information  are  required  and  identify  them  to  the  database 
management  system  for  retrieval.  The  database  management  system  is 
not  assumed  to  supply  the  capability  to  retrieve  stored  information 
according  to  content. 

The  information  stored  in  the  database  is  specific  to  the 
execution  of  air  missions.  In  order  for  a  user  to  make  intelligent 
use  of  this  information,  he  must  have  access  to  information  on  the 
current  battle  situation.  The  battle  situation  information  may  also 
be  stored  in  a  computer  database,  but  it  will  be  assumed  to  be 
separate  from  the  database  of  this  study. 

Although  tlv'  scope  of  investigation  has  been  narrowed,  it  has 
been  done  in  such  a  way  that  the  functional  effect  of  the  neglected 
portions  of  the  TACS  on  those  which  remain  will  be  minimal. 

Moreover,  our  approach  is  modular  in  the  sense  that  the  omissions 
could  be  incorporated  easily  at  a  later  date  if  desired.  For 
instance,  the  force  management  functions  for  airlift  missions  and 
interaction  with  the  Air  Lift  Control  Element  (ALCE)  could  be 
incorporated;  or  a  new  automation  concept,  such  as  more  mechanized 
functions  at  the  Tactical  Unit  Operation  Center  (TUOC) ,  could  be 
laid  over  the  current  concept. 

The  two  extensions  mentioned  above  art  representative  of  more 
detailed  or  enhanced  management  functions.  Another  direction  of 
possible  expansion  of  the  scope  of  this  study  would  be  the  inclusion 
of  other  TACS  functions.  There  would  probably  be  two  stages  to  such 
an  undertaking:  design  of  information  storage  and  retrieval  systems 
to  support  the  functions  of  each  of  the  other  TACS  components  on  the 
same  organizational  level  as  the  TACC,  the  management  of  materiel  by 
the  logistics  center  for  example;  then  design  a  distributed  system 
which  integrates  these  component  databases.  The  present  study  would 
play  an  important,  initial  role  in  such  an  expansion  by  providing  a 
design  lor  a  specific  component  database,  as  well  as  providing  a 
paradigm  for  design  of  components  databases. 

To  summarize,  our  interest  will  be  in  a  distributed  database  to 
support  force  management  functions,  for  the  tactical  air  missions 
listed  above,  with  responsibility  concentrated  at  the  TACC  and 
spiead  through  the  TACC  components  highlighted  in  Figure  1. 
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Summary  of  t.he  Basic  Model 


The  basic  tenet  of  our  approach  is  that  the  load  on  a 
distributed  database  system  will  be  determined  by  the  level  of  user 
activity  which  drives  the  database.  The  basic  transaction  workload 
model  reflects  this  transformation  of  user  activity  into  database 
load.  To  formulate  such  a  model,  one  needs  to  define  parameters  for 
measuring  user  activity,  parameters  for  measuring  database  load,  and 
a  mapping  from  the  former  to  the  latter. 

The  amount  of  user  activity  is  directly  related  to  the  number  of 
tactical  air  missions  executed  during  the  da/.  So,  we  use  mission 
levels  during  a  24-hour  cycle  as  our  user  activity  parameter. 

A  first  approximation  to  a  database  system,  satisfying  the  basic 
information  storage  and  retrieval  requirements,  is  defined  by  a 
small  set  of  very  general  files  along  with  rudimentary  file 
operations.  This  system  will  be  referred  to  as  the  information 
system.  To  parameterize  database  load  in  the  information  system, 
counts  will  be  kept  of  each  of  the  file  operations,  which  file  was 
affected,  and  the  source  of  entry  of  the  operations. 

The  mapping  from  user  activity  to  database  load  represents  the 
patterns  of  data  usage  in  carrying  out  the  force  management 
functions.  We  create  a  script  of  probable  user  actions  necessary  to 
carry  out  the  force  management  functions.  Each  action  identifies  a 
file,  a  file  operation,  and  the  source  of  entry  of  the  operation. 
Each  action  of  the  script  is  assigned  a  frequency  with  which  it  is 
likely  to  occur.  The  frequency  is  dependent  on  user  activity.  The 
quantified  script  provides  the  mapping  from  user  activity,  in 
mission  levels,  to  information  system  activity,  in  file  operation 
counts . 

The  quantified  script  provides  a  flexible  and  justifiable  format 
for  the  model.  The  motivation  for  inclusion  of  each  action  can  be 
justified.  Actions  can  be  removed,  added,  or  modified  as  the  need 
arises . 

Extensions  of  the  Model 


The  results  from  this  basic  model  can  be  used  for  more  detailed 
modeling  of  a  database  system,  as  well  as  for  early  design 
consideration.  Two  extensions  to  the  basic  model  are  considered  in 
this  paper.  One  reflects  an  operational  time  line  for  varying  user 
activities.  The  other  considers  the  effect  of  allocation  of  data 
files  within  the  network. 
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The  operational  time  line  is  represented  by  associating  an 
interval  of  occurrence  to  each  of  the  actions  of  the  quantified 
script.  Since  each  action  of  the  quantified  script  is  linked  with 
execution  of  the  force  management  functions,  we  assign  time 
intervals  to  each  of  the  functions  to  obtain  times  for  the  actions. 
With  this  time  line  we  can  determine  the  rate  at  which  the  various 
database  activities  occur  during  the  day. 

When  data  files  have  been  allocated  among  the  nodes,  '.ie  car 
begin  to  determine  the  communication  and  node  processing  loads.  A 
file  operation  entered  from  a  node,  other  than  that  holding  the 
file,  will  require  a  message  to  be  sent.  Thus,  knowing  the  sources 
of  file  operations  and  the  locations  of  the  files,  we  can  determine 
internode  message  counts.  By  examining  the  incoming  message  at  a 
node,  we  can  measure  processing  requirements  at  each  node. 

Contents  of  Paper 

The  structure  of  the  database,  upon  which  our  model  is  based,  is 
described  in  Section  2.  We  include  only  enough  detail  of  the  system 
to  enable  generation  of  quantitative  information  for  subsequent 
stages  of  system  design.  The  general  construction  of  the  basic 
transaction  workload  model  and  its  operation  are  discussed  in 
Section  3. 

The  representation  of  tactical  air  operation,  as  viewed  by  the 
model,  is  described  in  Section  4.  Output  from  the  basic  model 
representing  five  different  operational  scenarios  is  presented  and 
discussed  in  Section  5. 

The  basic  model  is  extended  to  include  an  operational  time  line. 
This  provides  rates  of  database  activity  during  the  day.  This  data 
is  presented  in  Section  6. 

The  location  of  data  files  within  the  network  is  discussed  and 
extensions  are  made  to  the  basic  model  to  include  file  location. 

Data  provided  by  this  extension  is  presented  in  Section  7. 

Section  8  summarizes  the  information  gained 
workload  model  and  its  extensions. 


from  the  transaction 


SECTION  2 

INFORMATION  SYSTEM 


GENERAL  DESCRIPTION 

The  information  system,  on  which  we  will  be  basing  our  model, 
consists  of  a  small  number  of  simply  structured  logical  files  and  of 
rudimentary  operations  performed  on  those  files. 

The  logical  files,  which  are  listed  in  Table  1,  were  obtained  by 
aggregating  relational  data  structures  defined  in  (LAMB78b) .  Those 
relational  data  structures  are  mission-dependent  in  definition.  To 
reduce  the  complexity,  similar  data  for  differing  mission  types  have 
been  unified  into  single  files.  We  will  need  only  a  general  notion 
of  the  contents  of  the  files,  although  a  more  detailed  description 
could  be  derived.  Appendix  A  details  the  correspondence  between  our 
logical  files,  and  the  relations  of  (LAM£78b) . 

Each  logical  file  will  comprise  a  collection  of  logical  records. 
Every  logical  record  is  assumed  to  have  a  unique  identifier  or  key 
through  which  operators  gain  access  to  individual  records. 

Knowledge  of  the  specific  data  content,  fields,  or  structure  of  the 
logical  records  will  not  be  necessary  at  this  time,  although  these 
could  be  derived  from  (LAMB78b). 

The  i  ile  operations  allowed  will  all  be  record-at-a-time 
operations.  That  is,  if  any  portion  of  a  logical  record  is  to  be 
retrieved  or  altered,  then  the  entire  record  must  be  retrieved  or 
altered.  The  file  operations  are  the  following: 

INSERT  -  A  new  logical  record  is  added  to  an  existing 
file.  The  system  provides  an  access  key. 

DELETE  -  The  logical  record,  whose  key  is  specified  by  the 
user,  is  removed  from  the  file. 

RETRIEVE  -  The  contents  of  a  logical  record,  whose  key  is 

specified  by  the  user,  are  displayed  to  the  user. 

REPLACE  -  The  entire  contents  of  a  logical  record,  whose  key 

is  specified  by  the  user,  are  replaced  by  user  supplied 
data . 
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There  will  be  five  types  of  nodes  within  the  distributed  system 
being  modeled,  which  are  consistent  with  the  TACS  components 
mentioned  in  the  introduction: 

TACC  -  Tactical  Air  Control  Center 


TUOC  -  Tactical  Unit  Operation  Center 
DASC  -  Direct  Air  Support  Center 
CRC  -  Control  and  Reporting  Center 
1C  -  Intelligence  Center 

Though  there  may  be  replication  of  some  of  these  components  for  a 
given  system  deployment,  e.g,,  there  are  eight  TUOC's  in  the 
deployments  of  (LAMB78a) ,  they  will  be  considered  equivalent  to  a 
single  "average"  node  in  the  network  for  this  model.  The  nodes  will 
be  of  interest  to  us  as  the  sources  from  which  the  file  operations 
originate.  They  will  also  be  candidate  sites  for  location  of  the 
logical  files  when  we  are  ready  to  include  that  detail. 


OVERVIEW  OF  INFORMATION  SYSTEM  USE 

The  functions  which  our  information  system  is  to  support  are 
planning,  monitoring,  directing,  and  controlling  of  tactical  air 
missions.  We  can  interpret  these  functions  as  follows  with  regard 
to  our  information  system: 

Planning  -  Insertion  of  data  for  specific  missions  into  the 
database , 

Monitoring  -  Checking  stored  data  to  insure  its  agreement 
with  the  physical  situation  or  overall  plans. 

Directing  -  Making  data  available  to  components  needing  it. 

The  sending  of  orders  or  directives  is  automatic 
in  the  system  envisioned.  Orders  are  posted  in 
the  database,  and  the  recipient  retrieves  them. 

Controlling  -  Updating  or  changing  stored  data  in  reaction  to 
changing  situations. 


One  further  function,  which  we  will  call  data  maintenance, 
consists  of  loading  or  purging  data  as  the  need  arises. 
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We  will  present  an  outline  of  the  manner  in  which  the 
information  system  is  used  for  the  planning  function  over  the  24- 
hour  cycle.  This  will  provide  an  indication  of  the  purpose  of  each 
logical  file,  and  provide  a  background  for  more  detailed  discussions 
in  Section  4. 

The  cycle  for  preplanned  missions  begins  with  storage  of 
information  on  targets  (TARGET)  and  requests  for  missions  against 
those  targets ,  along  with  recommendations  on  carrying  out  the 
missions  (M3NREQ) .  After  the  available  aircraft  have  been 
allocated  among  the  mission  types,  planners  at  the  TACC  begin 
retrieving  mission  requests  and  their  corresponding  targets,  and 
scheduling  missions  in  response  to  these  requests.  This  wing  level 
mission  scheduling  information  (MSNSCHEP)  is  stored,  so  that  it  can 
be  reviewed  later  in  its  totality,  and  then  retrieved  at  the  TUOC 
for  more  detailed  squadron  level  scheduling  (FLIGHT_SCHED) .  As  the 
missions  are  put  into  operation  and  carried  out,  mission  progress  is 
monitored  through  reports  which  are  stored  (REPORTS).  Returning  to 
the  wing  level  mission  scheduling  for  a  moment,  it  may  be  that  some 
of  these  missions  require  support  missions.  Thus,  the  planner  at 
the  TACC  would  enter  a  support  mission  request  (SUPPMSNREQ)  for 
later  processing.  The  support  missions  will  give  rise  to  their  own 
mission  schedules,  flight  schedules,  and  reports  which  will  also  be 
stored.  When  wing  level  mission  scheduling  has  been  done,  air 
refueling  requirements  can  be  determined  and  tanker  missions 
assigned  (TNKR  ASGNMT) .  We  do  not  consider  detailed  tanker  mission 
scheduling,  since  this  is  carried  out  by  an  organizational  entity 
outside  the  scope  of  our  investigation. 

Information  activity  for  mission  assignment  and  execution  is 
characterized  by  the  insertion  of  certain  logical  records  in  an 
approximate  chronological  sequence.  This  sequence  will  be  used  to 
help  decompose  the  24-hour  operational  cycle  into  phases.  An 
information  structure  for  preplanned  missions  can  be  conceived  as  a 
set  of  linked  logical  records  as  shown  in  Figure  2.  The  links  need 
not  be  one-to-one;  for  example,  many  TARGET  records  may  be  linked  to 
a  single  MSN_SCHED  record  implying  multiple  targets  for  a  single 
mission.  Or,  a  ground  alert  MSN_SCHED  would  have  no  TARGET  record 
linked.  The  information  structure  of  Figure  2  can  be  thought  to 
grow  from  left  to  right  as  insertions  are  made  during  the  life 
cycle.  The  captions  in  the  lower  margin  identify  the  chronological 
phase  during  which  the  records  above  are  inserted.  The  captions  of 
the  left  margin  identify  the  mission  types  to  which  the  adjacent 
records  pertain.  Primary  missions  comprise  all  preplanned  missions 
other  then  support  missions. 
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- PHASE  OEVELOPMENT - — 

/ - - - - S 

UATA  EORCE  PRIMARY  SUPPORT  TANKFR  ERAG  ENTRY  MISSION  OPERATION 

MAINTENANCE  ALLOCATION  MISSION  MISSION  MISSION  REVItW  SCMtOULING  MONITORING 

PLANNING  PLANNING  PLANNING 

Figure  2.  Preplanned  Mission  Information  Structure 


The  activity  of  immediate  mission  planning  is  performed  in  real 
time  response  to  immediate  mission  requests  entered  in  the  database, 
as  opposed  to  the  systematic  manner  in  which  preplanned  missions  are 
laid  out.  A  planner  has  the  option  of  either  activating  a  mission 
on  alert,  or  diverting  a  mission  in  progress.  In  either  case,  the 
primary  information  activity  will  be  updating  existing  records.  If 
an  alert  mission  is  activated,  its  MSN_SCHED  is  updated  to  indicate 
that  it  is  an  active  mission.  It  will  be  linked  to  a  TARGET  record, 
and  supplied  with  a  FLIGHTSCHED  record  if  it  was  a  ground  alert. 

To  divert  a  mission  in  progress,  a  new  or  additional  TARGET  will  be 
linked,  and  changes  may  be  made  in  the  MSN-SCHED  and  FLIGHT_SCHED 
records.  An  information  structure  for  alert  missions  is  shown  in 
Figure  3. 

This  discussion  has  been  only  an  outline  of  information 
activity.  In  order  to  construct  a  record  to  be  inserted,  an 
operator  will  have  to  retrieve  and  consult  much  information  already 
stored.  For  example,  before  scheduling  a  mission  a  planner  must 
know  what  resources  are  available  and  their  location.  These 
activities  and  more  will  be  described  in  Section  4. 
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DOTTED  ENTITIES  WILL  BE  SUPPLIED  ON  MISSION  ACTIVATION. 
"GENERATED  FOR  AIR  ALERT  OR  ACTIVATION  ONLY. 


Figure  3.  Alert  Mission  Information  Structure 
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SECTION  3 


BASIC  MODEL 


We  will  briefly  discuss  the  computational  structures  used  for 
the  basic  model.  A  more  detailed  account  is  given  in  Appendix  B. 

The  three  types  of  items  which  specify  the  information  system 
described  in  Section  2  are: 

.  logical  files 

.  logical  file  operations 

.  sources  of  entry  of  logical  file  operations 
These  items  are  reviewed  in  Figure  4.  The  parameters  which  will  be 
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RETRIEVE 
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Figure.  4.  Information  System  Constituents 
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used  to  measure  information  system  activity,  and  represent  output  to 
this  stage  of  modeling,  are  counts  of  particular  operations,  to 
particular  files  from  particular  sources;  for  example,  the  number  of 
INSERT  operations  to  the  MSNREQ  file  originating  from  the  DASC  as 
source.  The  counts  are  assembled  in  a  three-dimensional  array  whose 
dimensions  represent  operations,  files,  and  sources.  Thus,  the 
triple  (INSERT,  MSNREQ,  DASC)  can  be  used  to  locate  a  position  in 
the  array  of  counts,  and  the  corresponding  count  will  be  stored 
there.  The  array  will  be  referred  to  as  the  file  activity  array. 

The  input  to  the  model  will  be  counts  of  the  various  types  of 
air  missions  that  are  planned  and  executed  during  the  24-hour  period 
being  modeled.  The  tactical  air  missions  counted  are  shown  in 
Figure  5. 

PREPLANNED  AIR  ALERT 


• 

OFFENSIVE  COUNTER  AIR 

• 

AIR  DEFENSE 

t 

• 

AIR  INTERDICTION 

• 

AIR  INTERDICTION 

• 

CLOSE  AIR  SUPPORT 

• 

CLOSE  AIR  SUPPORT 

a 

RECONNAISSANCE 

GROUND  ALERT 

IMMEDIATE 

• 

AIR  DEFENSE 

• 

OFFENSIVE  COUNTER  AIR 

• 

AIR  INTERDICTION 

• 

AIR  INTERDICTION 

• 

CLOSE  AIR  SUpPORT 

• 

CLOSE  AIR  SUPPORT 

• 

RECONNAISSANCE 

• 

RECONNAISSANCE 

SUPPORT 

m-58,069 

Figure  5.  Tactical  Air  Missions 


To  perform  the  calculations  for  the  model,  a  list  of  probable 
operator  actions  is  compiled.  Each  action  will  contribute  to  only 
one  of  the  counts  in  the  file  activity  array.  For  example,  an 
operator  action  would  be  the  entry  at  the  DASC  of  the  day's  mission 
requirements  in  support  of  ground  forces.  This  action  could  affect 
the  count  located  at  the  position  in  the  array  indexed  by  (INSERT, 
MSNREQ,  DASC).  The  increment  to  that  count  will  be  computed  based 
on  the  mission  counts.  For  example,  suppose  that  it  is  determined 
empirically  that  20  percent  of  reconnaissance  requests,  80  percent 


%? 

Vi- 


14 


of  close  air  support  requests,  and  no  others  originate  at  the  DASC. 
Moreover,  requests  exceed  actual  missions  by  two  to  one.  Thus,  to 
determine  the  increment  to  the  count,  one  doubles  the  number  of 
reconnaissance  and  close  air  support  missions,  takes  20  percent  of 
the  former  and  80  percent  of  the  latter.  Each  action  is  described 
by  identifying  the  count  in  the  file  activity  array  to  be  changed 
and  by  providing  a  computational  expression  for  the  increment  in 
terms  of  the  input. 

The  computer  implementation  is  based  on  a  file,  each  of  whose 
records  describes  an  operator  action  in  the  position-increment  form. 
The  operator  action  file  will  be  referred  to  as  a  script.  A 
computer  program  processes  each  record  of  the  script  file  with  the 
mission  counts,  and  augments  the  file  activity  array.  When  the 
entire  script  is  processed,  the  array  is  on  its  final  form  and  ready 
for  output  or  further  processing. 

This  file  formats  a  very  flexible  representation  of  usage 
patterns,  since  actions  can  be  inserted,  deleted  or  altered  in  the 
file.  Moreover,  since  each  action  is  closely  tied  to  the  user 
functions  being  supported,  as  the  next  section  will  show,  the 
justification  for  each  action  can  be  examined. 
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SECTION  4 


TACTICAL  AIR  OPERATIONS 


In  this  section  we  will  describe  tactical  air  operations,  as 
viewed  by  the  model,  and  list  the  operator  actions  necessary  to 
carry  out  the  operations.  The  representation  of  these  actions  in 
quantifiable  form  for  use  in  the  computer  implementation  is 
relegated  to  Appendix  B. 

The  cycle  of  tactical  operations  is  generally  decomposed  into 
four  major  phases.  For  the  purposes  of  our  modeling  we  will  further 
refine  this  decomposition.  The  units  for  the  model  will  be  referred 
to  as  operational  phases.  There  is  a  chronology  to  the  phases  which 
will  be  discussed  in  more  detail  in  Section  6.  The  operational  and 
major  phases  are  listed  and  related  in  Table  2. 


Table  2 

Phases  of  Tactical  Air  Operations 


Major  Phases 

Operational  Phases 

Mission  Planning 

Force  Allocation 

Primary  Mission  Planning 
Support  Mission  Planning 
Tanker  Mission  Planning 

Frag  Entry  Review 

Flight  Scheduling 

Monitoring  and  Assessment 
of  Operations 

Operation  Monitoring 

Adjustment  and  Replacing 
of  Operations 

Immediate  Mission  Planning 
Operation  Adjustment 

Maintenance  of  Data 
and  Report  Generation 

L 

Data  Maintenance 

We  will  now 
phases  and  then 
actions  are  not 
phases . 


describe  the  nature  of  each  of  the  operational 
list  the  operator  actions  of  that  phase.  The 
necessarily  in  chronological  order  within  the 


FORCE  ALLOCATION 

This  task  comprises  determination  of  the  number  of  sorties 
available,  and  allocation  of  these  sorties  among  the  mission  types 
in  accordance  with  command  guidance.  It.  is  assumed  that  command 
guidance,  entered  as  percentages,  will  resolve  any  contention  for 
resources  among  different  mission  types.  The  database  activity 
during  this  task  is  independent  of  the  mission  level,  since  it 
consists  primarily  of  scanning  files.  Thus,  it  will  be  a  fixed 
overhead  depending  only  on  the  size  of  the  files  scanned. 

1.  Status  of  each  airbase  is  checked  to  determine  whether 
or  not  sorties  can  be  flown. 

2.  Status  of  aircraft/aircrew  at  each  airbase  is  checked 
to  determine  the  equipment  available. 

3.  The  sortie  rate  for  each  type  of  aircraft  at  each  airbase 
is  multiplied  by  the  number  of  aircraft  available  at  that 
airbase  to  give  the  number  of  sorties  available. 

4.  The  computed  number  of  sorties  for  each  aircraft  type  at 
each  airbase  is  stored. 

5.  The  overall  apportionment  by  mission  type,  which  embodies 
command  guidance,  is  stored. 

6.  The  distribution  of  sorties  available  3t  each  airbase 
from  each  squadron  among  the  mission  types  is  stored. 


PRIMARY  MISSION  PLANNING 

Planners  at  the  TACC  assign  the  allocated  available  sorties  to 
missions.  The  result  of  this  phase  will  be  mission  schedules 
(MSNSCHED),  one  for  each  primary  mission  planned.  (Primary 
missions  comprise  the  Preplanned,  Air  Alert,  and  Ground  Alert 
categories  shown  in  Figure  5.)  In  order  to  produce  each  of  these 
mission  schedules,  the  planner  will  need  to  consult  t^e  mission 
request  and  the  corresponding  target  data,  determine  the 
availability  of  munitions  critical  to  the  mission,  request  any 
support  missions  thought  necessary,  and  update  the  number  of 


aircraft  still  unassigned.  The  TUOC  whose  aircraft  are  being 
assigned  to  the  mission  may  check  the  mission  schedules  as  they  are 
generated  to  detect  any  incongruities. 

1.  Planner  inserts  mission  schedule  for  primary  mission. 

2.  Planner  views  a  number  of  requests  before  deciding 
which  request  for  a  primary  mission  to  fill. 

3.  Planner  views  target  data  for  some  or  all  of  the 
requests  viewed  in  //2. 

4.  Planner  enters  a  request  for  a  support  mission,  if 
it  is  needed. 

5.  To  make  sure  all  munitions  needed  for  a  primary 
mission  are  available,  the  planner  may  scan  the 
list  of  munitions  in  critical  supply. 

6.  As  soon  as  a  primary  mission  is  scheduled,  the 
planner  subtracts  the  number  of.  sorties  used  from 
the  number  of  sorties  available  for  subsequent 
primary  missions. 

7.  When  a  mission  has  been  planned,  the  DA5C  may  want 
to  review  its  nusrsion  schedule. 

8.  CRC  may  review  mission  schedule. 

9.  TUOC  may  review  mission  schedule. 

SUPPORT  MISSION  PLANNING 

In  response  to  tue  support  mission  requests,  a  TACC  planner 
generates  a  mission  schedule  for  each  escort  or  air  patrol  niission. 

A  single  support  mission  may  support  a  numDer  of  primary  missions. 

We  will  assume  that  the  support  resources  have  beer,  separately 
allocated  so  that  there  is  no  contention  for  aircraft  between  combat 
and  support  missions.  The  planning  process  is  roughly  the  same  as 
for  primary  missions. 

Assumption:  Support  resources  are  not  sufficient  to  fill  all 

requests  for  support.  Hence,  the  number  of  support  missions  will  be 
part  of  the  input  to  the  model.  The  alternative  is  to  determine 
empirically  the  percentage  of  primary  miss. ions  requiring  support. 
Then  the  number  of  support  missions  could  be  computed  from  the 
number  of  primary  missions. 
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1.  Planner  inserts  mission  schedule  data  for  a  support 
mission. 

2.  Planner  views  a  number  of  requests  for  support  before 
deciding  which  one  (or  ones)  to  fill. 

3.  Planner  views  schedules  of  preplanned  missions 

to  be  assisted  by  the  support  mission  being  planned. 

4.  The  list  of  critical  munitions  may  be  scanned  to  make 
sure  all  munitions  are  available  for  the  support  mission 
being  planned. 

5.  Sorties  used  are  subtracted  from  the  sorties  available. 

6.  When  the  support  mission  has  been  planned,  the  TUOC  may 
review  the  mission  schedule  for  inconsistencies. 

7.  CRC  reviews  support  mission  schedule. 

8.  DASC  reviews  support  mission  schedule. 


TANKER  MISSION  PLANNING 

When  primary  and  support  missions  have  been  planned,  a  tanker 
mission  planner  at  the  TACC  can  review  the  mission  schedules  to 
determine  which  missions  will  need  refueling  and  assign  tanker 
missions  (TNKRASGNMT)  accordingly. 

1.  Planner  enters  a  tanker  assignment  into  the  database. 

2.  Planner  scans  all  missions  to  determine  which  missions  will  need 
refueling. 

3.  Planner  views  mission  schedules  of  missions  to  be  refueled 
by  tanker  being  assigned. 


FRAG  ENTRY  REVIEW 

The  gross  mission  schedules  for  primary,  support,  and  tanker 
missions,  generated  so  far,  are  reviewed  to  verify  overall 
consistency  and  coordination  of  the  plan  for  the  day's  tactical  air 
operations.  Alterations  may  be  required  to  correct  deficiencies. 

1.  Each  of  the  schedules  will  be  reviewed  at  least  once 
to  insure  overall  consistency  of  the  frag  order. 
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2.  Some  mission  schedules  reviewed  may  require  alteration. 

3.  Mission  requests  may  be  rechecked. 

4.  Target  data  may  be  rechecked. 

5.  The  tanker  assigned  to  the  mission  may  be  reviewed. 

6.  Tanker  assignment  may  require  alteration. 

FLIGHT  SCHEDULING 

The  detailed  mission  assignment  at  the  squadron  level 
(FLIGHTSCHED)  is  done  at  the  TUOC  in  accordance  with  the  wing  level 
directives  of  the  mission  schedules.  We  will  not  be  considering 
tanker  flight  scheduling  for  this  model. 

1.  Each  air  mission  must  be  assigned  a  flight  schedule 
by  the  TUOC. 

2.  The  mission  schedule  of  each  air  mission  must  be  viewed 
at  the  TUOC  before  a  flight  schedule  can  be  chosen. 

3.  The  planners  at  TACC  may  check  the  flight  schedules  for 
overall  consistency. 

OPERATION  MONITORING 

Mission  progress  reports  for  active  missions  will  result  in 
either  updates  to  existing  mission  assignment  data,  or  entry  of 
mission  results  in  the  REPORT  file.  Table  3  summarizes  the  report 
type  and  data  altered. 

The  progress  of  the  ground  alert  missions  will  be  tracked  by 
updates  to  the  ALERT  file.  When  a  ground  alert  mission  is  begun,  a 
tecord  is  inserted  in  the  file.  When  the  alert  is  over  or  the 
mission  is  activated,  the  record  is  deleted  from  the  file.  Thus, 
there  will  be  one  insertion  and  one  deletion  for  each  ground  alert 
mission.  The  file  is  reviewed  in  handling  immediate  mission 
requests . 

1.  Mission  schedule  is  changed  by  the  TUOC  to  reflect 
the  reduced  number  of  aircraft  as  the  result  of 
aborts . 

2.  TUOC  enters  an  abort  report. 
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Table  3 

Mission  Reports 


Report  Title 

Frequency 

Source 

Data 

Af  f ected 

Mission  Cancel 

2°/0  of  missions 

TACC 

All 

Abort 

5%  of  missions 

DASC,  TUOC 

FRAG  ENT 

Ai r  Advisory 

2%  of  missions 

TUOC 

MSNSCHED 

Ground  Delay 

2%  of  missions 

TUOC 

MSN  SCHED 

Takeoff 

1  /mi ss i on 

TIJOC 

MSN_SCHED 

Landing 

1/mission 

TUOC 

MSN  SCHED 

Re  1  ue 1 i ng 

1/ref  uel 

CRC 

REPORT 

Reronna i ssance 

1 nf 1 ight 

1/target 

CRC,  DASC, 

TACC 

REPORT 

Fighter  Inflight 
/Ai rstri ke 

1/target 

CRC,  DASC 

REPORT 

— 

3.  Mission  schedule  changed  by  DASC  as  a  result  of  abort. 

4.  DASC  enters  an  abort  report. 

5.  Revised  flight  schedule  as  a  result  of  air  advisory 
entered  by  TUOC . 

6.  Flight  schedule  revised  by  TUOC  as  a  result  of  ground  delay. 

7.  Takeoff  and  landing  reports  are  entered  by  TUOC  on  the 
flight  schedule  for  each  mission  not  cancelled. 

8.  One  refueling  report  is  received  and  entered  by  CRC  for 
each  mission  refueled. 

9.  Inflight  report  received  and  entered  by  CRC. 


n 

a 
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10. 

Inflight  report 

entered  by  DASC. 

11. 

Inflight  report 

entered  by  TACC. 

12. 

Missions  alerted 
list  by  the  TUOC 

are  put  on  an  current  alert 

resources 

13. 

As  missions  go  off  alert  without  being  activated,  they 
are  removed  from  the  alert  resources  list  by  the  TUOC. 

IMMEDIATE  MISSION  PLANNING 

Missions  will  be  planned  by  the  TACC  to  meet  immediate  situation 
requirements  which  it  detects  itself,  or  as  reported  by  the  DASC. 
After  processing  an  immediate  mission  request,  there  are  three 
possible  modes  of  response  listed  here  in  their  order  of  preference: 
directing  an  air  alert  mission  to  the  target,  activating  a  ground 
alert  mission,  or  diverting  a  preplanned  mission  to  the  target. 

Process  Immediate  Mission  Request 

When  a  request  is  placed  for  an  immediate  mission  by  the  TACC  or 
DASC,  it  is  unlikely  that  the  required  target  information  is  stored; 
this  information  would  be  inserted.  In  response  to  an  immediate 
request,  a  TACC  planner  reviews  the  request  and  target  data,  then 
chooses  an  appropriate  mode  of  response.  The  available  alert 
resources  are  reviewed  and  mission  scheuules  of  any  suitable 
missions  are  inspected.  If  no  alert  mission  is  found  suitable,  the 
mission  schedules  of  preplanned  missions  are  scanned  until  a  mission 
is  found  suitable  for  diversion. 

Assumption:  Each  immediate  mission  request  results  in  an 

immediate  mission  being  scheduled.  No  requests  are  left  unfilled. 
Thus,  the  number  of  requests  equals  the  number  of  missions. 

1.  Requests  for  immediate  missions  entered  from  the  TACC. 

2.  Request  entered  from  the  DASC. 

3.  Target  data  of  corresponding  immediate  mission  is  entered 
by  TACC. 

4.  Target  data  entered  for  DASC  request. 

5.  Planner  retrieves  a  number  of  i  .mediate  mission  requests 
before  deciding  which  to  fill. 
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6.  Planner  views  target  data  at  least  once  for  each  request 
filled,  but  may  also  view  targets  in  choosing  request 

to  process. 

7.  Planner  scans  list  of  alert  resources  to  determine  whether 
or  not  any  of  these  are  appropriate  for  the  immediate 
mission  request. 

8.  Planner  views  the  mission  schedule  of  an  alert  mission  for 
possible  activation. 

9.  Planner  views  mission  schedules  of  preplanned  missions  for 
possible  diversion. 

Activate  Air  Alert  Mission 


When  an  air  alert  mission  is  to  be  activated,  the  TACC  must  make 
changes  to  the  data  in  its  mission  schedule,  change  mission  type 
from  alert,  insert  target,  etc.  The  request  should  be  marked  as 
filled  and  the  available  alert  resources  list  updated.  The  TUOC 
scheduler  will  make  changes  in  the  flight  schedule. 

10.  Mission  schedule  of  activated  mission  is  altered. 

11.  Flight  schedule  is  updated. 

12.  Request  marked  filled. 

13.  Mission  removed  from  the  alert  resources  list. 

Activate  Ground  Alert  Mission 


The  database  activities  would  be  the  same  as  those  for  an  air 
alert  mission  with  the  exception  that  a  flight  schedule  must  be 
inserted  by  the  TUOC,  rather  than  updated. 

14.  Mission  schedule  for  activated  ground  alert  mission 
is  altered. 

15.  Flight  schedule  is  entered  by  TUOC. 

16.  Request  is  marked  filled. 

17.  Mission  is  removed  from  the  alert  resources  list. 
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Divert  Preplanned  Mission 


The  mission  schedule  of  a  diverted  mission  will  be  changed  to 
reflect  a  new  or  additional  target,  and  the  flight  schedule  may  have 
to  be  altered.  The  refueling  and  support  mission  requirement  may 
need  change  as  well. 

18.  Change  mission  schedule  to  divert. 

19.  Request  is  marked  filled. 

20.  Update  the  flight  schedule. 

21.  Adjust  tanker  assignment  to  fill  refueling  needs. 

22.  Adjust  support  mission  coordination. 


OPERATION  ADJUSTMENT 

The  adjustments  in  this  phase  are  those  which  arise  because  of 
deviations  from  previous  plans,  time  delays,  resource  shortages, 
mission  cancellation  or  abort  reports.  The  adjustment  of  one 
mission  may  require  adjustment  of  other  missions  in.  order  to 
maintain  coordination.  For  example,  the  adjustment  of  a  combat 
mission  may  necessitate  adjustments  to  its  supporting  and  refueling 
missions;  or  conversely,  adjustment  of  a  tanker  mission  will  affect 
the  mission  it  refuels.  We  will  assume  that  the  totcl  effect  of  all 
of  these  interactions  is  reflected  in  the  models  computations. 

1.  Mission  schedule  of  cancelled  mission  is  removed  by  TACC. 

2.  Flight  schedule  of  cancelled  mission  is  removed  by  TUOC. 

3.  Request  for  support  mission  required  by  cancelled  mission 
is  removed  by  TACC. 

4.  Mission  schedule  of  a  mission  supporting  a  cancelled 
mission  is  adjusted. 

5.  Assignment  for  a  tanker  mission  refueling  a  cancelled 
mission  is  adjusted. 

6.  Mission  schedule  is  adjusted. 

7.  Flight  schedule  is  adjusted  by  TUOC  due  to  air  or  ground 
delay . 
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8.  Tanker  assignment  adjusted  to  maintain  rendezvous  with 
delayed  mission. 


DATA  MAINTENANCE 

We  will  not  consider  the  database  activity  for  report  generation 
in  this  model,  although  it  can  be  added  later.  The  activities  of 
this  operational  phase  consist  of  maintaining  data  on  the  status  of 
TACS  components,  entry  of  planning  information  for  the  next  day's 
missions,  and  removal  of  out-of-date  planning  information. 

For  resources  necessary  to  operations  of  the  tactical  air 
control  system,  the  maintenance  of  stored  information  is  done 
primarily  through  periodic  status  reports  from  the  various  units  of 
the  system  as  shown  in  Table  4.  A  report  will  consist  of  updating  a 
time  stamp  to  indicate  that  a  report  has  been  made,  then  making  any 
appropriate  revisions  to  the  stored  information. 

I^ble  4 

Status  Reports  from  TACS  Components 


Report/File  name 

Source 

Frequency 

TACS  Component  Status 

CRC ,  TUOC 

DASC ,  TACC 

Every  4  hours/unit 

Aircraft  Status 

TUOC 

3/day/unit/location 
aircraft  type 

Airbase  Status 

TUOC 

1  /day 

Critical  Munitions 

TUOC 

1/day 

1. 

CRC  < 

enters 

status 

report . 

2. 

TUOC 

enters 

status 

report 

3. 

DASC 

enters 

status 

report 

4. 

TACC 

enters 

status 

report 

5.  Each  TUOC  reports  three  times  daily  on  the  status  of  its 
aircraft  and  aircrews. 

6.  Each  TUOC  reports  daily  on  the  status  of  the  airbase 
equipment. 

7.  Munitions  which  have  reached  critically  low  levels  are 
entered  on  a  list. 

8.  Munitions  which  have  been  resupplied  are  removed  from 
the  critical  munitions  list. 

9.  Mission  requests  entered  by  DASC. 

10.  Mission  requests  entered  by  IC. 

11.  The  target  data  for  the  next  day's  mission  is  entered 
in  the  database. 

12.  Mission  requests  purged. 

13.  Mission  schedules  purged. 

14.  Old  target  list  purged. 

15.  Support  mission  requests  purged. 

16.  Flight  schedule  purged. 

17.  Old  reports  purged. 
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SECTION  5 


RESULTS  OF  THE  BASIC  MODEL 


In  this  section  we  will  describe  some  of  the  results  obtained 
from  the  basic  model.  As  yet  we  have  made  no  mention  of  the 
location  of  the  files.  The  information  obtained  at  this  stage  of 
the  modeling  is  intended  primarily  to  assist  in  optimal  placement  of 
the  files  within  the  network;  this  will  be  taken  up  in  Section  7. 
Some  of  the  questions  that  we  will  be  able  to  answer  in  this  section 
are : 


-  Who  will  be  the  heaviest  users? 

-  Which  are  the  most  active  files? 


-  What  are  the  strongest  user-file  ties? 

We  can  also  investigate  the  changes  in  the  answers  to  these 
questions  as  a  result  of  changes  in  mission  level  input. 

The  mission  levels  and  computational  constants  used  in 
constructing  and  driving  the  present  version  of  the  model  were 
derived  from  a  training  scenario  for  a  Korean  deployment  as 
described  in  (NERA76).  The  computational  constants  we  refer  to  are 
parameters  such  as  the  ratio  of  tanker  missions  to  fighter  missions 
or  the  average  numbers  of  targets  per  fighter  mission. 


The  effect  of  variation  in  mission  levels  on  database  activity 
is  one  of  the  primary  interests  of  this  work.  The  scenarios  used 
were  all  derived  as  variations  on  the  Korean  training  scenario.  All 
aspects,  other  than  mission  levels,  are  assumed  to  be  the  same  as 
those  of  the  training  scenario.  The  scenarios  are  as  follows: 


STP1 


The  basic  mission  levels  taken  directly 
from  the  scenario. 


STP1MAX 


All  mission  levels  were  raised  by  50  percent. 


STP1MIN  -  All  mission  levels,  except  reconnaissance, 
were  lowered  by  60  percent.  Reconnaissance 
missions  stayed  at  the  basic  level. 

STP10CA  -  All  suitable  multi-mission  aircraft  in  the  STP1 
scenario  were  shifted  to  offensive  counter  air 
or  air  interdiction  missions. 


STP1CAS  -  All  suitable  multi-mission  aircraft  in  the  STP1 

'  scenario  were  shifted  to  close  air  support  missions. 

The  mission  levels  for  each  of  these  scenarios  are  shown  in 
Table  5.  Each  set  of  mission  levels  was  entered  in  the  model  and 
the  resulting  file  activity  array  accumulated.  The  array  was 
subjected  to  additional  processing  to  produce  data  tailored  to  our 
interest. 


Table  5 

Scenario  Mission  Levels  (Number  of  Missions/Day) 


Mission  Type 

Scenario 

STP1 

STP1MAX 

STP1MIN 

STP10CA 

STP1CAS 

Preplanned  Offensive 

34 

51 

11 

34 

20 

Counter  Aii 

Preplanned  Air  Interdiction 

10 

15 

3 

50 

1 

Preplanned  Close  Air  Support 

20 

30 

6 

0 

43 

Preplanned  Reconnaissance 

52 

78 

52 

52 

32 

Air  Alert  Air  Defense 

7 

11 

2 

7 

7 

Air  Alert  Air  Interdiction 

6 

9 

2 

0 

0 

Air  Alert  Close  Air  Support 

5 

8 

1 

0 

1 1 

Ground  Alert  Air  Defense 

3 

5 

1 

3 

3 

Ground  Alert  Air  Interdiction 

4 

6 

1 

0 

0 

Ground  Alert  Close  Air  Support 

5 

8 

1 

C 

9 

Ground  Alert  Reconnaissance 

48 

72 

48 

48 

48 

Support 

6 

9 

2 

6 

6 

Immediate  Offensive  Counter  Air 

10 

15 

3 

10 

10 

Immediate  Air  Interdiction 

10 

15 

3 

0 

0 

Immediate  Close  Air  Support 

10 

15 

3 

0 

20 

Immediate  Reconnaissance 

48 

72 

48 

48 

48 

Total 

278 

419 

187 

258 

278 

The  percentage  of  total  database  usage  for  each  of  the  TAGS 
components  is  shown  in  Table  6.  The  figure  listed  for  the  TUOC 
represents  the  combined  usage  of  the  eight  TUOCs  of  the  scenario. 
As  one  might  expect  from  the  scope  of  the  study,  the  highest  usage 
is  by  the  TACC. 

The  most  active  files  can  be  identified  from  Table  7,  which 
shows  the  percentage  of  total  file  activity  aimed  3t  each  of  the 
files.  Note  that  the  CRITICAL  MUNITIONS  file  is  one  of  the  most 
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Table  6 


Database  Usage  by  TACS  Components  (Percent  of  Total  Daily  Usage) 


Component 

Scenario 

STP 

STP 1 MAX 

STP1M1N 

STP 1 OCA 

STP 1 CAS 

TACC 

78.08 

76.74 

71.69 

77.55 

75.45 

TUOC 

11.61 

11.51 

12.39 

11.14 

11.76 

CRC 

2.67 

2.58 

2.51 

2.98 

2.41 

DASC 

4.83 

5.08 

6.78 

4.16 

6.21 

IC 

2.82 

4.09 

6 . 64 

4.17 

4.17 

Table  7 

Scenario  File  Activity  (Percent  of  Total  Daily  Usage) 


File 

Scenario 

STP1 

STP1MAX 

STP1MIN 

STP10CA 

STP 1  CAS 

TARGET 

8 

09 

7 

90 

9 

76 

9 

53 

7 

52. 

MSN  RF.Q 

13 

98 

11 

66 

19 

68 

15 

25 

13 

83 

SUP  MSN  REQ 

0 

29 

0 

30 

0 

14 

0 

13 

0 

44 

MSN  SCHED 

24 

50 

25 

47 

27 

26 

22 

84 

26 

02 

FLIGHT  SCHED 

5 

54 

5 

76 

5 

20 

5 

67 

5 

66 

REPORT 

2 

43 

2 

52 

2 

07 

3 

19 

2 

02 

1MMED  MSN  REQ 

1 

93 

2 

00 

2 

30 

1 

32 

i 

98 

ALERT 

12 

09 

12 

5  3 

15 

24 

8 

55 

12 

35  j 

CRITICAL  MUNITIONS 

27 

63 

28 

91 

13 

63 

29 

95 

26 

69  1 

TACS  STATUS 

0 

45 

0 

31 

0 

74 

0 

46 

0 

46 

AIRBASE  STATUS 

0 

1 1 

0 

08 

0 

18 

0 

1 1 

0 

1 1 

AIRCRAFT  STATUS 

0 

88 

0 

61 

1 

43 

0 

90 

0 

90 

SORTIE  AVAIL 

1 

59 

1 

58 

1 

81 

1 

63 

1 

63  | 

SORTIE  RATE. 

0 

22 

0 

15 

0 

36 

0 

22 

0 

22  ; 

OVERALL  APPORT 

0 

01 

0 

00 

0 

01 

0 

01 

0 

01  1 

UNIT  APPORT 

0 

.08 

0 

05 

0 

12 

0 

08 

0 

08 

TNKR  ASGMNT 

0 

.17 

0 

17 

0 

09 

0 

17 

0 

09 

31 


active.  This  is  a  result  of  the  fact  that  the  contents  of  that  file 
are  scanned  frequently  during  planning,  giving  rise  to  a  large 
number  of  retrievals. 

As  an  indication  of  the  size  to  which  the  files  may  grow, 

Table  8  shows  the  total  number  ot  inserts  made  to  each  file  during 
the  24-hour  cycle.  Note  that  records  are  never  inserted  in 
TACSSTATUS ,  AIRBASESTATUS ,  or  SORTIE_RATE.  These  are  seen  as 
permanent  files  of  fixed  lengths  which  are  only  updated. 


Table  8 

Scenario  File  Insertions  (Number  of  Insert! ons/Day) 


File 

Scenario 

STP1 

STP1MAX 

STP1MIN 

STP10CA 

STP1CAS 

TARGET 

178 

200 

154 

148 

168 

MSN  REQ 

778 

778 

778 

778 

778 

SUP  MSN  REQ 

18 

27 

5 

6 

27 

MSN  SCHED 

200 

302 

130 

200 

200 

FLIGHT  SCHED 

208 

313 

133 

197 

208 

REPORT 

177 

266 

95 

22  7 

144 

IMMF.D  MSN  REQ 

78 

117 

57 

58 

73 

ALERT 

78 

119 

56 

58 

78 

CRITICAL  MUNITIONS 

2 

2 

2 

2 

2 

TAGS  STATUS 

0 

0 

0 

0 

0 

ATRBASE  STATUS 

0 

0 

0 

0 

0 

AIRCRAFT  STATUS 

96 

96 

96 

96 

96 

SORTIE  AVAIL 

32 

32 

32 

32 

32 

SORTIE  RATE 

0 

0 

0 

0 

0 

OVERALL  APPORT 

1 

1 

1 

1 

1 

'IN IT  APPORT 

11 

11 

11 

11 

11 

. NKRASGMNT 

5 

8 

2 

5 

2 

Total 

1862 

2272 

1552 

1819 

1825 
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SECTION  6 


TIME  LINE  EXTENSION  TO  THE  BASIC  MODEL 


The  results  shown  in  Section  5  applied  to  the  entire  24-hour 
planning  and  execution  cycle.  This  time  period  is  too  long  to 
provide  the  amount  of  detail  required  for  much  of  the  analysis.  We 
should  like  to  answer  questions  such  as: 

-  What  is  the  time  of  peak  activity? 

-  What  are  the  peak  loads? 

-  How  large  will  the  files  grow? 

-  When  is  each  TACS  component  busiest? 

To  provide  the  type  of  information  needed,  we  augment  the 
structure  of  the  basic  model  with  a  time  line.  We  obtain  the  time 
line  by  assigning  a  duration  end  to  each  of  the  operational  phases. 

The  time  line  upon  which  the  results  of  this  section  are  based 
is  shown  in  Figure  6,  and  is  only  hypothetical.  The  Oth  hour  is  an 
arbitrary  starting  point  for  the  cycle.  The  time  line  by  which 

OS'*! 


phase: 

FORCE  ALLOCATION 
PRIMARY  MISSION  PLANNING 

support  mission  planning 

'lANrftP  MISSION  PLANNING 

FRAG  ENTRY  REVIEW 

FLIGHT  SCHEDULING 

OPERATION  MONITORING  j 

IMMEDIATE  MISSION  PLANNING 

OPERATION  ADJUSTMENT 

DAI  A  MAINTENANCE 


- r — , — r — | - , - j- - 1 - 1 - T  r  i - r 

o  2  4  6  8  10  12  14  lb  IB  20  22  24 

CURATlON  iHOUHSI 


Figure  6.  Operational  Time  Line 
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tactical  air  operations  are  carried  out  will  profoundly  affect  the 
performance  and  design  of  a  distributed  database  system.  The  effect 
certainly  warrants  future  investigation  to  which  our  model  is  well 
suited. 

Activity  rates  for  each  of  the  five  scenarios  are  graphed  in 
Figure  7.  Notice  that  the  rates  for  the  STP1,  STP1MAX,  and  STP1MIN 
maintain  a  reasonably  constant  relationship  to  one  another.  On  the 
other  hand,  STP10CA  requires  more  planning  and  less  adjustment  than 
STP1,  while  STP1CAS  requires  less  planning  than  STP1. 

|iV>7.9?6l 


A  -  STP! 

B  STP1MAX 
C  -  STP1MIN 
D  STP10CA 
E  -  STP1CAS 


TIME  IHUUHSI 

Figure  7.  System  Activity  Levels 


We  would  also  like  to  know  the  effect  of  changing  the  mix  of 
mission  levels  on  the  relative  activity  levels  of  each  of  the  TACS 
components.  These  changes  in  mix  are  represented  through  scenarios 
STP1,  STP10CA,  and  STP1CAS.  Figures  8,  9,  and  10  present  graphs  of 
activity  levels  for  each  of  the  components.  Each  graph  pertains  to 
a  separate  scenario.  The  activity  levels  from  each  scenario  over  24 
hours  are  broken  down  by  TACS  component  in  Figures  11  through  15. 

The  units  for  all  of  this  data  are  file  operations  per  hour. 
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TIME  (HOURS) 


anew  a3d  SNOiivawo  m i 


2  4  6  8  10  12  14  16  ID  20  22  24 


TIME  (HOURS) 

Figure  14.  DASC  Activity  Levels 


2  4  0  8  10  12  14  10  18  20  22  24 


TIME  (HOURS) 

Figure  15.  IC  Activity  Levels 
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SECTION  7 


FILE  ALLOCATION 


The  location  of  the  data  in  a  distributed  database  system  is 
critical  to  the  performance  of  the  system.  In  this  section  we  will 
show  how  the  results  of  the  basic  model  can  be  used  to  choose  an 
optimal  file  allocation,  and  we  will  show  how  the  file  allocation 
can  be  incorporated  in  the  model  to  provide  quantitative  data  for 
the  design  of  the  communication  and  node  processor  subsystems. 

The  file  allocation  strategy  chosen  is  largely  dependent  on  the 
cost  function  used  to  establish  optimality.  The  selection  of  an 
appropriate  cost  function  is  beyond  the  scope  of  this  paper. 
However,  in  this  section  we  will  investigate  two  allocation 
strategies  which  seem  intuitively  reasonable,  and  which  can  be 
implemented  with  the  information  on  hand.  The  two  strategies  are: 

Source  precedence  -  A  file  is  stored  at  the  node  which  is 

the  most  frequent  source  of  record  entry 
to  the  file. 

Usage  precedence  -  A  file  is  stored  at  the  node  where  the 

highest  usage  of  the  data  in  the  file 
occurs . 


SOURCE  PRECEDENCE  STRATEGY 

The  rationale  behind  the  source  precedence  strategy  is  that 
insertion  is  the  most  difficult  of  the  file  operations,  and  this 
difficulty  is  compounded  by  performing  the  operation  from  a  remote 
point  in  the  network.  This  strategy  is  intended  to  minimize 
processing  costs.  Total  daily  counts  of  insertions  to  each  file  are 
tabulated  in  Tables  9  through  13  for  each  of  the  scenarios. 

Two  copies  of  each  file  are  allocated  to  insure  an  increased 
degree  of  data  survival.  The  copies  are  assigned  to  the  two  sources 
of  highest  insertion  rates  as  determined  from  Tables  9  through  13. 
The  TACC  and  CRC  are  used  as  alternate  sites  of  assignment,  since 
the  TACC  is  the  focus  of  functions  being  supported  and  the  CRC  is  to 
serve  as  backup  to  the  TACC.  Thus,  copies  of  the  file  are  placed  at 
the  TACC  and  CRC,  in  that  order,  unless  other  sources  have  higher 
insertion  rates.  The  results  of  this  file  allocation  strategy  are 
shown  in  Table  14.  There  was  some  concern  that  changing  the 
scenario  would  change  the  results  of  the  allocation  strategy. 
However,  this  seems  not  to  be  a  problem  since  all  scenarios  led  to 
the  same  allocation. 
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Table  9 

File  Insertions  for  STP1  Scenario  (Number  of  Insertions/Day) 


Kile 

TACC 

TUOC 

Source 

CRC 

DASC 

1C 

TARGET 

123 

0 

0 

45 

O 

MSN  REQ 

0 

0 

0 

183 

505 

SUP  MSN  RKQ 

18 

0 

0 

0 

0 

MSN  SCHF.D 

200 

0 

0 

O 

0 

PLIGHT  SCHED 

0 

208 

0 

0 

0 

REPORT 

0 

4 

170 

3 

0 

I MMED  MSN  RKQ 

23 

0 

0 

55 

0 

ALERT 

0 

78 

0 

0 

0 

CRITICAL  MUNITIONS 

0 

2 

O 

0 

0 

TAGS  STATUS 

0 

0 

0 

0 

0 

AIRBASK  STATUS 

0 

0 

O 

0 

0 

AIRCRAFT  STATUS 

0 

96 

0 

O 

0 

SORT IK  AVAIL 

32 

0 

0 

0 

0 

SORTIE  RATE 

0 

0 

0 

O 

0 

OVERALL  APPORT 

1 

0 

0 

O 

0 

UNIT  APPORT 

1  1 

0 

0 

0 

0 

TNKR  ASGMNT 

5 

0 

0 

O 

0 

Table  10 

File  Insertions  for  STP1MAX  Scenario  (Number  of  Insertions/Day) 


Ki  Ie 

Source 

TACC 

TUOC 

CRC 

DASC 

1C 

TARGET 

134 

0 

0 

68 

0 

MSN  RKQ 

0 

0 

0 

IS  3 

595 

SUP  MSN  RKQ 

27 

0 

0 

0 

0 

MSN  SCHKD 

302 

O 

0 

0 

0  i 

|  FLIGHT  SCHKD 

0 

313 

0 

0 

0  1 

j  REPORT 

0 

6 

255 

4 

0  1 

!  IMMKI)  MSN  RKQ 

34 

0 

0 

83 

0 

!  ALERT 

0 

1  19 

0 

0 

0  1 

1  CRITICAL  MUNITIONS 

!  0 

2 

0 

0 

o  1 

j  TACS  STATUS 

'  0 

0 

O 

0 

0 

j  AIRBASE  STATUS 

:  o 

O 

O 

0 

0 

i  AIRCRAFT  STATUS 

1  0 

96 

0 

0 

°  i 

|  SORTIE  AVAIL 

!  32 

O 

0 

0 

o  ! 

|  SORTIE  RATE 

:  o 

0 

0 

0 

0 

;  OVF.KAI  1.  APPORT 

i 

0 

O 

0 

o 

!  UNIT  APPORT 

1 1 

O 

0 

0 

a 

1  TNKR  ASGMNT 

:  8 

O 

0 

0 

0 

i 
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Table  11 

File  Insertions  for  STP1MIN  Scenario  (Number  of  Insert. ions/Day) 


File 

Source 

TACC 

TUOC 

CRC 

DASC 

1C 

TARGET 

118 

0 

0 

36 

0 

MSN  REQ 

0 

0 

0 

183 

595 

SUP  MSN  REQ 

5 

0 

0 

0 

0 

MSN  SCKED 

130 

0 

0 

0 

0 

FLIGHT  SCHED 

0 

133 

0 

0 

0 

REPORT 

0 

2 

89 

2 

0 

IMMED  MSN  REQ 

18 

0 

0 

39 

°  1 

ALERT 

0 

56 

0 

0 

o 

CRITICAL  MUNITIONS 

0 

2 

0 

0 

0  ! 

TACS  STATUS 

0 

0 

0 

0 

0 

AIRBASE  STATUS 

0 

0 

0 

0 

0  : 

AIRCRAFT  STATUS 

0 

96 

0 

0 

0 

SORTIE  AVAIL 

32 

0 

0 

0 

0 

SORTIE  RATE 

0 

0 

0 

0 

0 

OVERALL  APPORT 

1 

0 

0 

0 

0 

UNIT  APPORT 

11 

0 

0 

0 

0 

TNKR  ASGMNT 

2 

0 

0 

0 

0 

Table  12 

File  Insertions  for  STP10CA  Scenario  (Number  of  Insertions/Day) 


File 

TACC 

TUOC 

Source 

CRC 

DASC 

1C 

TARGET 

116 

0 

0 

32 

0 

MSN  REQ 

0 

0 

0 

183 

595 

SUP  MSN  REQ 

6 

0 

0 

0 

0 

MSN  SCHED 

200 

0 

0 

0 

0 

FLIGHT  SCHED 

0 

197 

0 

0 

0 

REPORT 

0 

4 

220 

3 

0 

IMMED  MSN  REQ 

16 

0 

0 

42 

0 

ALERT 

0 

58 

0 

0 

0 

CRITICAL  MUNITIONS 

0 

2 

0 

0 

0 

TACS  STATUS 

0 

0 

0 

0 

0 

AIRBASE  STATUS 

0 

0 

0 

0 

0 

AIRCRAFT  STATUS 

0 

96 

0 

0 

0 

SORTIE  AVAIL 

32 

0 

0 

0 

0 

SORTIE  RATE 

0 

0 

0 

0 

0 

OVERAl.i,  APPORT 

I 

0 

0 

0 

0 

UNIT  APPORT 

1 1 

0 

0 

0 

0 

TNKR  ASGMNT 

-s 

0 

0 

0 

0 

1  . J 

- 

.  - - - 
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Table  13 

File  Insertions  for  STP1CAS  Scenario  (Number  of  Insertions/Day) 


TARGET 
MSN  REQ 
SUPMSN  REQ 
MSN  SCHED 
FLIGHTSCHED 
REPORT 

IMMEDMSNREQ 

ALERT' 

CRITICALtfllNITIONS 
TACS  STATUS 
AIRBASESTATUS 
AIRCRAFTSTATUS 
SORTTF.  AVAIL 
sortie'rate 

OVERALL  APPORT 
UNIT  APPORT 
TNKR  ASGMNT 


Source 


0 

595 

0 

0 

0 

0 

0 

0 

0  I 
0 

0  I 
0  I 

0  i 

0  i 
0 

0  j 

0  i 


Table  14 

File  Locations  (Source  Precedence  Strategy) 


TARGET 
MSN  REQ 
SUPMSN  REQ 
MSN  SCHED 
FLIGHT  SCHED 
REPORT 

IMMED  MSNREQ 
ALERT 

CRITICAL  MUNITION 
TACS  STATUS 
AIRBASE  STATUS 
AIRCRAFT  STATUS 
SORTIE  AVAIL 
SORTIERATE 
OVERALL  APPORT 
UNIT  APPORT 
TNKR  ASGMNT 


Location 

TACC 

TUOC 

CRC 

DASC 

IC 
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USAGE  PRECEDENCE  STRATEGY 


The  rationale  for  the  usage  precedence  strategy  is  that  the 
total,  system-wide  cost  of  performing  database  operations  is 
independent  of  the  node  at  which  they  are  performed.  Hence,  the 
only  cost  variable  with  file  location  is  the  communication  cost. 

So,  the  optimal  allocation  minimizes  the  number  of  messages  sent 
over  the  network  by  locating  the  file  at  the  point  of  highest  usage. 
Total  daily  counts  of  all  file  operations  to  each  file  are  tabulated 
in  Tables  15  through  19  for  each  scenario. 

If  we  assume  that  the  data  critical  to  the  operation  of  the  node 
is  the  data  most  often  used,  then  this  strategy  can  be  seen  to  have 
the  additional  benefit  of  tending  to  store  critical  data  at  the 
node.  This  would  lead  to  a  more  functionally  reliable  system,  since 
critical  data  would  still  be  available  as  long  as  the  node  exists; 
regardless  of  loss  of  communications  or  loss  of  other  nodes. 

Again,  two  copies  of  each  file  are  assigned,  with  the  TACC  and 
CRC  as  alternative  sites.  As  before,  we  find  that  the  file 
allocation  does  not  depend  on  scenario.  The  allocation  is  shown  in 
Table  20. 


Table  15 

Total  File  Activity  for  STP1  Scenario  (Number  of  Insertions/Day) 


File 

Source 

Total 

TACC 

TUOC 

CRC 

PASC 

1C 

TARGET 

1133 

0 

0 

45 

0 

1178 

MSN  REQ 

1258 

0 

0 

183 

595 

2036 

SUE  MSN  REQ 

A3 

0 

0 

0 

0 

43  | 

MSN  SCKED 

2176 

744 

200 

447 

0 

3567 

FLIGHT  SCHED 

280 

527 

0 

0 

0 

807 

REPORT 

177 

A 

170 

3 

0 

354 

IMMKD  MSN  REQ 

226 

0 

0 

55 

0 

281 

ALERT 

1516 

244 

0 

0 

0 

1760 

CRITICAL  MUNITIONS 

4019 

4 

0 

0 

0 

4023 

TACS  STATUS 

6 

48 

6 

6 

0 

66 

AIRBASE  STATUS 

8 

8 

0 

0 

0 

16 

AIRCRAFT  STATUS 

32 

96 

0 

0 

0 

128  1 

SORTIE  AVAIL 

232 

0 

0 

0 

0 

232 

SORTIE  RATE 

32 

0 

0 

0 

0 

32  j 

OVERALL  A P PORT 

1 

0 

0 

0 

0 

' 

UNIT  APPORT 

1 1 

0 

0 

0 

0 

1  1 

TNKR  ASGMNT 

24 

0 

0 

0 

0 

24 

TOTAL 

11174 

1675 

376 

7  39 

595 

14559 

_ 
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Table  16 


Total  File  Activity  for  STP1MAX  Scenario  (Number  of  Insertions/Day) 


TARGET 
MSN  REQ 
SUPMSN  REQ 
MSN_ SCHED 
FLIGHT  SCHED 
REPORT 

IMMED  MSNREQ 
ALERT 

CRITICAL  MUNITIONS 
TACS_STATUS 
AIRBASE  STATUS 
AIRCRAFT  STATUS 
SORTIE  AVAIL 
SORT  IE  RATE 
|  OVERALL  APPORT 
I  UNIT  APPORT 
TNKR  ASGMNT 


^  TOTAL  j : 


TACC  TUOC 

1599  0 

|  1682  0 

64  0 

3276  H23 

i  422  794 

266  6 

339  0 

2274  370 

;  6098  9 

I  6  48 


CRC  DASC  IC 


Table  17 


Total  File  Activity  for  STP1MIN  Scenario  (Number  of  Insertions/Day) 


TUOC  CRC 


DASC  1C 


TARGET 
MSN  REQ 
SUP 'MSN  REQ 
MSN  SCHED 
FLIGHT  SCHED 
REPORT 

IMMED  MSN  REQ 
ALERT 

CRITICAL  MUNITIONS 
TACS  STATUS 
I  AIRBASE  STATUS 
AIRCRAFT  STATUS 
SORTIE  AVAIL 
SORTIE  RATE 
OVERALL  APPORT 
UNIT  APPORT 
TNKR  ASGMNT 


608  595 


874 

1765 

12 

2443 

465 

|  186 
I  20b 
|  1366 

!  1221 
66 

I  16 

|  128 
I  162  I 

32  ! 

1 

1 1 
8 

!  8962 

J _ I 


Table  18 


Total  File  Activity  for  STP10CA  Scenario  (Number  of  Insertions/Day) 


File 

TACC 

TUOC 

Source 

CRC 

DASC 

IC 

ToLa  1 

TARGET 

1 329 

0 

0 

32 

0 

1361 

MSN  REQ 

1 398 

0 

0 

183 

595 

2176  I 

SUP  MSN  REQ 

19 

0 

0 

0 

0 

19  | 

MSN  SCHED 

1980 

753 

200 

327 

0 

3260 

FLIGHT  SCHED 

298 

512 

0 

0 

0 

810  1 

REPORT 

227 

4 

220 

3 

0 

454 

IMMED  MSN  REQ 

147 

0 

0 

42 

0 

189 

ALERT 

1056 

164 

0 

0 

0 

1220 

CRITICAL  MUNITIONS 

4271 

4 

0 

0 

0 

4275  ! 

TACS  STATUS 

6 

48 

6 

6 

0 

66  1 

AIRBASE  STATUS 

8 

8 

0 

0 

0 

16  j 

AIRCRAFT  STATUS 

32 

96 

0 

0 

0 

128 

SORTIE  AVAIL 

232 

0 

0 

0 

0 

232 

SORTIE  RATE 

32 

0 

0 

0 

0 

32 

OVERALL  APPORT 

1 

0 

0 

0 

0 

1 

UNIT  APPORT 

1 1 

0 

0 

0 

0 

11 

TNKR  ASGMNT 

24 

0 

0 

0 

0 

24 

TOTAL 

1  1071 

1589 

426 

593 

595 

14274 

Table  19 

Total  File  Activity  for  STP1CAS  Scenario  (Number  of  Insertions/Day) 


Fi  le 

Source 

Total 

TACC 

TUOC 

CRC 

DASC 

IC 

TARGET 

1019 

0 

0 

52 

0 

1071 

MSN  REQ 

1 193 

0 

0 

183 

595 

1971 

SUP  MSN  REQ 

62 

0 

0 

0 

0 

62 

MSN  SCHED 

2185 

744 

200 

579 

0 

3708  1 

FLIGHT  SCHED 

280 

527 

0 

0 

0 

807 

REPORT 

144 

4 

137 

3 

0 

288 

IMMED  MSN  REQ 

220 

0 

0 

62 

0 

282  , 

ALERT 

1516 

244 

0 

0 

0 

1760 

CRITICAL  MUNITIONS 

3800 

4 

0 

0 

0 

3804  ■ 

TACS  STATUS 

6 

48 

6 

6 

0 

66  ' 

AIRBASE  STATUS 

8 

8 

0 

0 

0 

In 

AIRCRAFT  STATUS 

32 

96 

0 

0 

0 

128 

SORTIE  AVAIL 

232 

0 

0 

0 

'  0 

'  232 

SORTIE  RATE 

32 

0 

0 

0 

0 

32 

OVERALL  APPORT 

1 

0 

0 

0 

0 

1 

UNIT  APPORT 

1 1 

0 

0 

0 

0 

11 

TNKRASGMNT 

13 

0 

0 

0 

0 

;  13 

TOTAL 

10754 

1 

1675 

343 

885 

595 

i  14252 

i  .  .J 
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Table  20 

File  Location  (Usage  Precedence  Strategy) 


File 

Location 

TACC 

TUOC 

CRC 

DASC 

1C 

TARGET 

X 

X 

MSN  RF.Q 

X 

X 

SUP  MSN  REQ 

X 

X 

MSN  SCHED 

X 

X 

FLIGHT  SCHED 

X 

X 

REPORT 

X 

X 

1MMED  MSN  REQ 

X 

X 

ALERT 

X 

X 

CRITICAL  MUNITIONS 

X 

X 

TAGS  STATUS 

X 

X 

AIRBASE  STATUS 

X 

X 

AIRCRAFT  STATUS 

X 

X 

SORTIE  AVAIL 

X 

X 

SORTIE  RATE 

X 

X 

OVERALL  APPORT 

X 

X 

UNIT  APPORT 

X 

X 

TNKR  ASGMNT 

X 

X 

MESSAGE  TRAFFIC. 

Once  a  file  allocation  has  been  chosen,  each  of  the  database 
operations  may  be  viewed  as  a  message  sent  by  the  node  initiating 
the  operation  to  the  node  (or  nodes)  where  the  file  is  located. 

Note  that  some  of  these  messages  may  go  from  a  node  to  itself.  By 
keeping  counts  of  these  messages  one  can  get  a  measure  of  the  load 
on  the  logical  links  cf  the  communication  network.  The  load  on  the 
local  database  systems  is  reflected  in  the  counts  of  incoming 
messages  at  the  node. 

When  the  operation  is  insertion,  replacement,  or  deletion,  a 
message  must  be  sent  to  each  node  possessing  a  copy  of  a  multiple 
copy  file.  This  assures  agreement  among  the  copies  of  the  file. 

Only  one  message  is  needed  for  a  retrieval,  but  there  should  be  some 
mechanism  for  choosing  the  optimal  copy  to  retrieve.  We  will  use 
the  physical  distance  between  nodes  as  a  retrieval  criterion  since 
it  should  be  roughly  proportional  to  communication  cost.  A  more 
accurate  criterion  would  require  more  detailed  design  information. 
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The  interriode  distance  were  derived  from  map  coordinates 
p.ovided  by  the  physical  deployment  portion  of  the  i'.orean  training 
scenario.  These  coordinates  have  been  normalized  to  a  100  x  100 
grid.  The  resulting  physical  layout  is  represented  in  figure  16. 

Icr  the  purpose  of  initial  simplification,  we  have  heen  considering 
the  TUOC  as  a  single  node  in  the  network,  whereas  the  scenario 
specifies  eight  TUOCs.  We  will  persist  in  this  assumption  by 
assigning  a  distance  between  the  ficticious  TUOC  node  and  other 
nodes  which  is  the  average  distance  over  all  the  TUCCs.  The  basis 
and  conclusions  of  these  calculations  are  shown  in  Table  21.  All  of 
the  internode  distances  are  tabulated  in  Table  22. 
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Figure  lb.  TAGS  Components  -  Physical  Deployment 


Table  21 


Normalized  Distances  Between  TUOC's  and  Components 


TIIOC 

Component 

TACC 

CRC 

DASC 

IC 

TUOC-1 

32.7 

30.4 

22.9 

31.6 

TUOC-2 

.  49.3 

46.6 

42.9 

49.3 

TUOC-3 

23.4 

23.5 

34.5 

21.2 

TUOC-4 

46.8 

47 . 1 

36.6 

44.6 

TUOC-5 

20.0 

22.3 

69.3 

21.2 

TUOC-6 

0,0 

2.7 

50. 1 

2.2 

TUOC-7 

63.8 

61.9 

15.8 

62 . 4 

TUOC-8 

70.4 

72.2 

120.5 

72.1 

Average 

38.3 

36.3 

49.1 

38.1 

Table  22 

Inter-component  Normalized  Distances 


TACC 

TUOC 

CRC 

DASC 

1C 

TACC 

0.0 

38.3 

2.7 

50.  1 

2.2 

TIJOC 

38.3 

0.0 

38.3 

49.  1 

38.1 

CRC 

2.7 

38.3 

0.0 

48.5 

3.5 

DASC 

50.  1 

49. 1 

48.5 

0.0 

48.4 

1C 

2.2 

38.  1 

3.5 

48.4 

0.0 
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Network  messages  arise  when  a  file  is  not  located  at  the  source 
of  entry  of  a  file  operation.  Table  23  shows  network  message 
traffic  for  each  of  the  scenarios  along  with  the  percentage  of  file 
operations  that  cannot  be  performed  at  their  source.  The  usage 
precedence  strategy  has  a  significant  impact  in  lowering  network 
message  traffic  as  we  would  expect.  The  percentage  of  file 
operations  requiring  network  involvement  has  been  reduced  by  10 
points  for  all  scenarios.  It  is  interesting  to  note  that  this 
percentage  rises  as  the  number  of  missions  drop  from  STP1MAX  to 
STP1MIN.  This  is  probably  due  to  the  increasing  significance  of  the 
mission  independent  background  and  the  apparent  internode 
characteristic  of  that  background. 


Table  23 

Daily  Network  Message  Traffic 


Scenario 

Allocation  Strategy 

Usage 

Precedence 

Source 

Precedence 

Messages 
per  Day 

Percent 
of  Total 

Messages 
per  Day 

Percent 
of  Total 

STP1 

4948 

26.5 

6790 

36 . 4 

STF1MAX 

6542 

24.7 

9172 

34.7 

STP1MIN 

3815 

31.5 

42. 1 

STP10CA 

4619 

25.4 

6660 

36.7 

SIP 1 CAS 

5069 

27.6 

6813 

37. 1 

For  the  design  of  the  physical  communication  network,  one  would 
like  information  on  the  message  loads  on  each  of  the  logical  links 
of  the  network.  This  information  can  be  derived  from  the  message 
count  array.  The  numbers  of  messages  from  each  source  to  each 
destination  are  shown  in  Tables  24  through  28  for  each  of  the 
scenarios  and  both  allocation  strategies. 


49 


Table  24 


Daily  Component  to  Component  Messages  for  STP1  Scenario 


Destination 

Source 

Total  (In) 

TACC 

“ 

TUOC 

CRC 

DASC. 

1C 

- — — —  1 

Usage  Precedence 

TACC 

11174 

935 

376 

295 

228 

13095 

TUOC 

874 

1671 

6 

453 

0 

3092 

CRC 

465 

4 

170 

3 

0 

642 

DASC 

'J47 

0 

0 

100 

0 

447 

1C 

412 

0 

0 

183 

228 

822 

'  Total  (Out) 

13270 

2786 

532 

1034 

456 

1 

Source  Precedence* 

; 

!  TACC 

973S 

1739 

6 

109 

0 

11613  ] 

;  TUoc 

403 

963 

170 

3 

0 

1541  ! 

;  ckc 

111! 

64 

376 

456 

0 

2007  ] 

;  DASC 

739 

0 

0 

283 

228 

1270 

'  IC 

123  7 

0 

0 

183 

228 

1668 

r» 

at 

c 

i  1327  1 

1 

2786 

352 

1034 

"J _ 1 

Table  25 

Daily  Component  to  Component  Messages  for  STP1MAX  Scenario 


Dos  t  i  rial. i  on 

Source 

Total  (In) 

TACC 

TUOC 

CRC 

DASC 

1C 

Usage  Precedence 

TACC 

16692 

1456 

563 

444 

343 

19500 

TUOC 

1315 

2567 

6 

680 

0 

4568 

CKC 

678 

6 

255 

4 

0 

943 

;  DASC 

420 

0 

0 

151 

0 

571 

!  C 

t>23 

0 

0 

279 

345 

1247 

1  Total  (Out  ) 

19  728 

4029 

824 

1558 

690 

\ 

i  Source  Precedence 

j  TACC 

145)1 

2567 

6 

161 

0 

17267 

1  mot: 

609 

1394 

255 

4 

0 

2262 

|  CKC 

1630 

68 

363 

684 

0 

2965 

;  DASC 

104 

0 

0 

430 

345 

1818 

!  l(- 

1893 

0 

0 

279 

345 

2517 

|  Total  C Out.  3 

;  19  728 

4029 

824 

1338 

690 
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Table  26 


Dally  Component  to  Component  Messages  for  STP1MIN  Scenario 


Destination 

Source 

Total  (In) 

TACC 

TUOC 

CRC 

DASC 

IC 

Usage  Precedence 

TACC 

6206 

712 

225 

197 

80 

7420 

TUOC 

SSI 

1179 

6 

348 

0 

2084 

CPC 

280 

2 

89 

*1 

0 

373 

DASC 

304 

0 

0 

75 

0 

379 

1C 

192 

0 

0 

112 

80 

384 

!  Total  (Out) 

1 

7533 

1893 

320 

734 

160 

| 

1 

1  Source  Precedence 
j 

!  TACC 

5346 

1179 

6 

83 

0 

6614 

|  TUOC 

232 

654 

89 

2 

0 

977 

CRC 

692 

60 

225 

350 

0 

1327 

!  DASC 

496 

0 

0 

187 

HO 

763  ' 

:  ic 

767 

0 

0 

112 

80 

959  J 

j  Total  (Out) 

7533 

.  .. 

1893 

320 

734 

160 

! 

Table  27 

Daily  Component  to  Component  Messages  for  STP10CA  Scenario 


Dest i nation 

Source 

Total  (in)] 

1 

TACC 

TUOC 

CRC 

DASC 

1C 

Usa^e 

Precedence 

TACC 

11085 

990 

426 

193 

339 

13013 

TUOC 

766 

1735 

6 

333 

0 

2840 

CRC 

491 

4 

220 

3 

0 

718 

DASC 

291 

0 

0 

74 

0 

365 

1C 

426 

0 

0 

87 

339 

852 

Total 

(Out) 

13059 

2729 

652 

670 

678 

I 

l  Source  Precedence 

i 

TACC 

9446 

17)5 

6 

83 

0 

1 1270 

TUOC 

424 

930 

220 

3 

0 

1577 

I  CRC 

1060 

64 

426 

336 

0 

1886 

1  DASC 

717 

O 

c 

161 

339 

1217 

1  IC 

1412 

0 

0 

87 

339 

1838 

j  Total 

(Out) 

|  13059 

1 

2729 

652 

670 

678 

1 

•j 

j 


'-'■J 

•i 


* 
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Table  28 

Daily  Component  to  Component  Messages  for  STP1CAS  Scenario 


Des ti nat ion 

Source 

Total  (In) 

TACC 

TUOC 

CRC 

DASC 

IC 

Usage  Precedence 

TACC 

10752 

1023 

343 

413 

123 

12654 

TUOC 

914 

1759 

6 

585 

0 

3264 

CRC 

446 

4 

137 

3 

0 

590 

DASC 

334 

0 

0 

114 

0 

448 

IC 

410 

0 

0 

287 

123 

820 

Total  (Out) 

12856 

2786 

486 

1402 

246 

j  Source  Precedence 

TACC 

9417 

1754 

6 

123 

0 

11305 

TUOC 

372 

963 

137 

3 

0 

1475 

!  CRC 

1132 

343 

588 

0 

2127 

1  DASC 

744 

0 

0 

401 

123 

1268 

1  1C 

1191 

.0 

0 

287 

123 

1601 

j  Total  (Out) 

12856 

2786 

48b 

1402 

246 

The  incoming  file  operation  messages  will  determine  the  amount 
of  processing  power  required  at  each  of  the  nodes  of  the  network. 

All  incoming  messages  will  invoke  operations  on  files  located  at  the 
node.  We  categorize  the  messages  as  native  if  they  originate  at  the 
node  with  the  file,  or  foreign  if  they  originate  elsewhere.  The 
incoming  message  flow  at  each  node  for  the  STPl  scenario  and  usage 
precedence  file  allocation  strategy  is  represented  in  Table  29. 
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Incoming  Message  Flow  (STP1,  Usage  Precedence) 
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Table  29  (Cont'd) 
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SECTION  8 


SUMMARY  AND  CONCLUSIONS 


In  this  paper  we  have  described  the  design,  implementation,  and 
use  of  a  mathematical  model  which  relates  user  activity  to  the 
database  load  to  support  that  activity.  The  model  and  extensions 
are  used  to  investigate  the  application  of  distributed  database 
technology  to  support  the  force  management  functions  of  a  tactical 
air  control  system. 


OBSERVATIONS 

The  results  from  the  basic  model  show  that,  for  the  chosen 
scenario  and  operations  concept,  70  to  80  percent  of  the  database 
activity  originates  at  the  TACC.  As  one  might  expect,  some  of  the 
load  shifts  to  the  DASC  when  the  mission  mix  is  skewed  toward  close 
air  support  missions  since  these  missions  involve  the  DASC  far  more 
than  the  other  components.  However,  the  shift  is  rather  small. 

The  importance  of  file  scanning  in  performance  is  indicated  by 
the  activity  on  the  CRITICAL_MUNITIQNS  and  ALERT  files  which  are  two 
of  the  most  active.  When  an  immediate  mission  request 
(IMMEDMSNREQ)  is  entered,  the  ALERT  file  is  scanned  to  determine 
whether  any  alert  resources  are  suitable.  This  calls  for  six 
retrievals  from  the  ALERT  file  (the  average  number  of  records  in  the 
ALERT  file)  to  each  insertion  to  IMMED_MSN_REQ.  This  ratio  of  one 
to  six  is  approximately  the  ratio  of  the  file  activities  of  the  two 
files  as  shown  in  Table  7. 

The  time  line  analysis  of  Section  6  reveals  that  the  peak  system 
load  occurs  during  the  fifth  hour  of  the  daily  cycle  as  shown  in 
Figure  7.  This  peak  corresponds  to  the  period  of  review  of  the  frag 
order  before  it  is  finalized.  There  are  from  1000  to  2500  file 
operations  per  hour  during  that  peak  period.  This  also  appears  to 
be  the  peak  period  for  each  of  the  individual  components,  as  shown 
in  Figures  11  through  15. 

It  is  also  observed  from  Figure  7  that  changing  the  mission  mix 
has  a  noticeable  effect  on  the  variation  of  file  activity  rate 
during  the  day.  The  time  line  employed  breaks  roughly  into  two 
periods  -  planning  (0-8  hour)  and  monitoring  (8  -  20  hour). 
Shifting  toward  offensive  counter  air  missions  yields  about  an  8 
percent  increase  in  planning  activity  and  a  2U  percent  decrease  in 
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monitoring  activity.  Shifting  toward  close  air  support  gives  a  2 
percent  decrease  in  planning  activity  and  no  change  in  monitoring. 

The  information  in  Table  23  of  Section  7,  derived  from  the  file 
allocation  extension  to  the  model,  shows  that  network  message 
traffic  can  be  reduced  by  25  to  30  percent  with  a  usage  precedence 
file  allocation  strategy  as  opposed  to  the  source  precedence 
strategy.  The  true  significance  of  this  reduction  will  be  apparent 
only  when  more  details  of  the  implementation  are  considered,  such  as 
record  length,  message  overhead,  and  communication  and  processing 
costs . 

From  Tables  24  through  28  it  might  appear  that  the  TACC  to  TUOC 
communication  channel  is  the  busiest.  However,  this  is  not  really 
the  case  since  our  TUOC  node  represents  an  aggregate  of  eight 
TUOC's.  With  this  in  mind,  all  channels  appear  to  be  under 
approximately  the  same  message  load. 

Under  either  file  allocation  strategy  -  source  precedence  or 
usage  precedence  -  the  TACC  has  the  highest  number  of  incoming 
messages,  and  hence  the  heaviest  file  processing  load.  In  fact,  the 
load  on  the  TACC  is  an  order  of  magnitude  greater  than  that  on  each 
of  the  other  nodes.  Again  the  true  significance  will  emerge  only 
when  more  implementation  details  are  added. 

It  is  true  that  usage  precedence  reduces  message  traffic,  but  at 
the  cost  of  increased  processing  load  at  the  TACC  as  shown  by  the 
total  number  of  incoming  messages  to  the  TACC  in  Tables  24  through 
28.  So  the  comparative  value  of  each  strategy  would  have  to  be 
established . 


CONCLUSIONS 

Based  on  the  data  derived  from  this  stage  of  modeling,  there  are 
very  few  apparent  reasons  for  distributing  the  database.  Since  so 
much  of  the  activity  originates  at  the  TACC,  the  tendency  would  be 
toward  a  centralized  database  located  at  the  TACC  with  terminal 
access  from  the  other  nodes.  The  primary  reason,  however,  for 
distribution  of  the  data  is  to  decrease  vulnerability  to 
destruction.  This  reason  alone  may  be  sufficient.  Another 
plausible  reason  for  distribution  is  to  allow  the  TACC  to  shed  some 
of  its  processing  load  onto  other  components. 

The  bias  toward  centralization  is  probably  a  result  of  the  set 
of  functional  requirements  used  to  construct  the  model; 
particularly,  the  set  of  files  chosen  and  the  view  of  user  activity 
represented  in  the  script  file.  The  requirements  were  obtained  from 
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system  specifications  for  a  centralized  database  for  the  TACC  and 
reflect  that  approach.  One  of  the  areas  for  further  work  is  the 
development  of  truly  "distributed"  system  requirements.  This  could 
be  done  by  assigning  some  of  the  TACC  functions  to  lower  echelon 
components  (e.g.,  part  of  the  mission  scheduling  done  at  wing  level) 
or  by  providing  for  computer  assistance  to  the  functions  intrinsic 
to  the  lower  echelon  components  (e.g.,  computer  assisted  route 
planning  at  the  TUOC).  Such  information  has  been  difficult  to 
obtain  since  it  does  not  pertain  to  the  current  mode  of 
organization. 

One  of  the  shortcomings  of  this  study,  due  to  its  limited 
scope,  is  the  failure  to  consider  the  full  function  of  each  of  the 
components.  For  example,  the  CRC  has  many  functions  which  do  not 
relate  directly  to  force  management,  but  which  would  create  a  load 
on  any  computer  and  communication  system  used.  Thus,  to  design  the 
system  based  solely  on  the  force  management  function  would  leave  it 
woefully  inadequate  to  support  the  totality  of  C3  functions.  These 
sorts  of  difficulties  had  been  anticipated  and  the  model  has  been 
made  flexible  enough  to  permit  adjustments. 

The  operational  scenario  under  which  the  system  is  to  run  will 
have  an  effect  on  the  loads.  However,  some  of  these  effects  do  not 
seem  to  be  as  profound  as  had  been  imagined.  The  changes  in  mission 
levels  induced  some  shifting  of  load,  but  the  change  was  primarily 
an  overall  increase  or  decrease  of  database  activity.  This 
observation  needs  further  investigation  within  different  scenarios. 

Another  aspect  of  the  operation  which  will  have  a  significant 
impact  on  system  design  is  the  time  line  by  which  the  functions  are 
carried  out.  There  appears  to  be  no  consensus  on  precisely  what  the 
time  line  should  be.  The  time  line  used  in  this  paper  is  a 
realistic  representation  of  one  approach  to  TAGS  operation  in  which 
the  day's  missions  are  planned  and  then  execu.....  Another  approach, 
giving  a  totally  different  time  line,  would  be  to  plan  the  next 
day's  mission  while  the  current  day’s  missions  are  being  executed. 
The  latter  approach  would  probably  distribute  system  activity  more 
evenly  over  the  day,  leading  to  a  lower  peak  load. 

Results  to  date  exhibit  the  use  of  the  transaction  workload 
model  for  a  given  operational  setting.  However,  the  approach  taken 
to  modeling  provides  a  tool  suitable  for  investigation  of  a  wide 
range  of  operations  concepts,  scenarios  and  database  distribution 
alternatives.  Work  is  currently  underway  to  establish  a  set  of  more 
distributed  system  requirements.  Some  additional  scenario  data  has 
been  obtained  and  is  being  used  in  the  model.  Other  file  allocation 
strategies,  both  heuristic  and  quantitative,  are  being  considered. 
Message  sizes  are  currently  being  derived  to  enabl  •  determination  of 
load  on  communication  channel. 
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APPENDIX  A 


LOGICAL  FILE  STRUCTURE 


The  logical  files  employed  in  the  information  system  were 
derived  by  unifying  relational  data  structures  of  (LAMB78b). 

Whenever  possible,  similar  data  for  differing  mission  types  was 
unified.  The  succeeding  tables  relate  the  logical  files  to  the  more 
detailed  relational  data  structures.  The  numeric  entries  in  the 
tables  refer  to  the  relation  numbers  of  (LAMB78b). 
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Table  A-l 


Mission-Dependent  Data  (Relation  Numbers  from  LAMB78b) 


Mission  Type 

Logical  File 

MSN_REQ 

MSN_SCHED 

SUPMSNREQ 

Preplanned  Counter  Air 
and  Air  Interdiction 

1A,  2,  3 

73,  29,  72, 
40,  17C ,  59, 
15C ,  61,  16C 

14, 

18C 

Preplanned  Close 

Air  Support 

4,  2A,  3A 

14,  40,  16 
26,  15,  59 

17 

Ground  Alert  Close 

Air  Support  and  Air 
Interdiction 

6 ,  8 

14,  40,  16A 

none 

Air  Alert  Close  Air 
Support  and  Air 
Interdiction 

7,  8A 

14,  40,  16A 
15B 

none 

Ground  Alert 
Reconnaissance 

32,  8B 

14,  40,  8B 
52,  34 

none 

Preplanned 

Reconnaissance 

35,  35B 

36 

14,  40,  36, 
59,  51,  54, 
73,  29 

72, 

48, 

49 

Ground  Alert  Air 

Defense 

38 

14,  40,  44 

none 

Air  Alert 

Air  Defense 

39 

14,  40,  46, 

45 

none 

Support  (Air  Patrol 
and  Escort) 

none 

24,  59,  60, 
73,  29,  23, 
68 

72, 

67, 

none 

Tanker 

none 

74,  73,  29, 

28 

none 
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Table  A-l  (Concl'd) 


Mission-Dependent  Data  (Relation  Numbers  from  LAMB78b) 


Mission  Type 

Logical  File 

REPORTS 

FL1GHTSCHED 

IMMEDMSN  REQ 

Preplinucu  Counter  Air 
and  Air  Interdiction 

101 ,  105 

14A,  58 

91 

Preplanned  Close 

Air  Support 

101,  106 

14A,  22 

91 

Ground  Alert  Close 

Air  Support  and  Air 
Interdiction 

none 

none 

none 

Air  Alert  Close  Air 
Support-  and  Air 
Interdiction 

102 

22A 

none 

Ground  Alert 
Reconnaissance 

none 

none 

none 

Preplanned 

Reconnaissance 

1 

101,  107 

14A,  51 

92,  93 

Ground  Alert 

Air  Defense 

none 

none 

none 

Air  Alert 

Air  Defense 

102 

65 

none 

Support  (Air  Patrol 
and  Escort) 

101,  108 

14A,  66 

none 

Tanker 

r  — 

»—» 

o  o 

OJ 

* 

o 

v£> 

none 

none 
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on  Numbers  from  LAMB78b) 


Relations 


APPENDIX  B 


COMPUTER  IMPLEMENTATION  OF  MODEL  AND  EXTENSIONS 


This  appendix  will  discuss  seme  of  the  details  of  the  computer 
implementation  of  the  transaction  workload  model  and  derivation  of 
the  results  presented  in  this  paper.  These  programs  were  developed 
using  computing  facilities  at  RADC  through  the  ARPANET.  The 
programs  were  written  in  APL  because  of  its  array  handling  ability 
and  its  ability  to  evaluate  character  strings  as  computational 
expressions.  The  present  implementation  consists  of  three  major 
segments  -  a  basic  model  and  two  extensions.  The  extensions 
introduce  the  additional  details  of  time  lines  and  file  allocation. 
A  block  diagram  of  the  implementation  is  shown  in  Figure  B-l. 


(BASIC  MODEL} 


I 

-I 


-  I 
II- 


Figure 

i 


B-l . 


ComnuLer  Implementation  Diagram 
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BASIC  MODEL 


The  input  to  the  basic  model  is  a  16-component  vector  of  mission 
counts  for  the  24-hour  period. 

The  output  for  the  model  is  a  three-dimensional  file  activity 
array.  The  array  can  be  processed  further  to  produce  insights  into 
a  variety  of  aspects  of  performance.  Or,  the  array  can  be  processed 
in  conjunction  with  additional  data  for  a  more  detailed 
representation  of  system  implementation. 

The  mapping  from  input  to  output  is  accomplished  by  a  virtual 
file  representing  a  script  of  operator  actions.  Each  record  has 
four  fields: 


(OPERATION,  FILE,  SOURCE,  FREQUENCY) 

The  first  three  fields  of  each  record  index  a  position  in  the  file 
activity  array,  while  the  fourth  specifies  an  increment  to  that 
array  position,  computed  from  the  input.  The  model  program 
pro'cesses  each  record  of  the  script  file  and  accumulates  increments 
to  the  file  activity  array  toward  the  final  value  of  the  array. 

Additional  computational  constants,  called  structural 
parameters,  are  employed  in  the  FREQUENCY  expressions  for  computing 
increments.  These  parameters  are  of  two  types  and  are  generally 
related  to  the  physical  deployment  of  the  system  being  modeled:  the 
number  of  certain  items  in  the  deployment,  such  as  the  number  of 
TUOC's  deployed;  average  ratios  between  certain  activities,  such  as 
the  average  number  of  air  missions  refueled  by  a  tanker  mission,  or 
the  average  number  of  requests  reviewed  by  a  mission  planner. 

A  number  of  computer  functions  are  provided  to  facilitate 
creation  and  manipulation  oi  the  script  file,  and  to  tailor  the 
output  data  to  a  variety  of  needs. 


TIME  LINES 

The  script  file  is  segmented  according  to  the  operational  phase 
to  which  the  actions  belong.  Each  segment  contains  all  operator 
actions  for  a  single  operational  phase.  To  superimpose  a  finer  time 
line  than  the  24-hour  period  on  the  activities  of  the  basic  model, 
we  assign  a  period  of  duration  to  each  operational  phase.  The 
records  of  a  single  segment  are  processed,  and  the  file  activity 
array  accumulated.  The  entries  of  the  array  are  ail  divided  by  the 
duration  of  the  phase  corresponding  to  the  segment  just  processed. 
This  yields  an  array  of  file  activity  rates.  We  follow  this 
procedure  for  each  of  the  segments  of  the  script  file.  To  obtain 
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information  about  the  situation  at  any  time  during  the  24-hour 
cycle,  we  determine  which  phases  are  in  operation  at  that  time  and 
process  their  file  rate  arrays  according  to  our  needs.  Usually  this 
involves  generating  a  numeric  array  to  be  used  by  a  graphics 
function. 

These  computations  assume  that  the  file  activity  rates  are 
uniform,  which  is  probably  not  realistic.  It  would  seem  reasonable 
to  expect  that  planning  rates  decrease  exponentially  with  time, 
while  monitoring  and  adjustment  rates  would  have  Gaussian 
distributions.  We  could  have  accommodated  these  factors  in  the 
model,  but  they  would  have  been  purely  speculative. 


MESSAGE  TRAFFIC 

We  collect  counts  of  messages  to  measure  network  loads.  The 
messages  are  classified  by  operation,  file,  source,  and  destination. 
For  example,  we  will  have  a  count  of  the  number  of  INSERT  messages 
to  MSNREQ  file  sent  from  the  DASC  to  the  CRC.  These  counts  are 
assembled  in  an  array  similar  to  the  file  activity  array,  except 
that  this  array  is  indexed  by  quadruples  rather  than  triples. 

The  message  counts  are  obtained  by  processing  our  three- 
dimensional  file  activity  array  in  conjunction  with  file  location 
information  and  inter-coinponent  distances.  The  index  of  each  count 
in  the  file  activity  array  will  supply  the  initial  portion  of  an 
index  into  the  message  count  array.  We  examine  the  file  involved  to 
supply  the  destir  ition  segment  of  the  message  count  index.  If  the 
operation  is  other  than  retrieval,  the  destinations  will  be  each  of 
the  components  where  a  copy  of  the  file  is  located.  The  fiie 
activity  count  is  inserted  at  each  of  these  indexed  positions  in  the 
message  count  array.  If  the  operation  is  retrieval,  then  the  inter- 
component  distances  are  consulted  to  determine  the  closest  component 
with  a  copy  of  the  file.  That  component  is  used  as  the  single 
destination. 

For  example,  suppose  the  count  in  the  (INSERT,  MSN_REQ,  DASC) 
position  of  the  file  activity  array  is  43,  and  that  copies  of  the 
file  are  located  at  the  CRC  and  TACC.  Then  43  will  be  entered  in 
the  (INSERT,  MSNREQ ,  DASC,  CRC)  and  (INSERT,  MSN_REQ ,  DASC,  TACC) 
positions  in  the  message  count  array.  On  the  other  hand,  if  the 
operation  were  RETRIEVE  we  would  have  to  consult  the  inter-component 
distances  to  determine  which  is  closer  to  the  DASC,  the  CRC  or  TACC. 
If  it  is  CRC ,  then  only  the  (RETRIEVE,  MSN_REQ,  DASC,  CRC)  position 
receives  the  43  from  the  file  activity  array. 
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Functions  are  provided  to  accomplish  the  mapping  from  the  file 
activity  array  to  the  message  counts  array,  and  to  further  process 
the  message  array  for  tailored  output. 


SCRIPT  FILE 

The  contents  of  the  script  file  will  be  presented  and  explained 
by  segment  in  Tables  B-l  through  B-10.  The  file  is  segmented 
according  to  the  operational  phase  during  which  the  operator  actions 
occur  (Primary  Mission  Planning,  Force  Allocation,  etc.).  The 
descriptions  of  the  actions  listed  in  Section  4  are  repeated  here 
for  each  operational  phase,  along  with  the  file  segment  representing 
the  actions.  Any  structural  parameters  used  in  the  increment 
calculations  will  be  explained.  Their  values  are  given  in  Table 
B-ll.  The  structural  parameters  beginning  with  the  prefix  N 
represent  the  number  of  an  item  present  in  the  deployment  modeled. 
For  example,  NTUOC  is  the  number  of  TUOC's.  The  other  parameters 
are  named  with  a  literal  followed  by  two  digits.  The  digits 
identify  the  phase  to  which  the  structural  parameter  pertains.  The 
first  digit  identifies  the  major  phase  and  the  second  digit  the 
operational  phase  within  that  major  phase.  The  literals  within 
phases  are  then  chosen  to  make  the  parameter  unique.  This  naming 
convention  is  actually  a  relic  of  a  previous  organization  of  the 
work. 


STRUCTURAL  PARAMETERS 

The  values  of  the  structural  parameters  used  to  derive  the  data 
for  this  paper  are  shown  in  Table  B-ll.  These  values  were  computed 
from  the  training  scenario  arid  assumed  to  extend  to  the  other 
scenarios . 
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Script  File  Segment:  PRIMARY  MISSION  PLANNING 
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Script  File  Segment:  SUPPORT  MISSION  PLANNING 
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5  MISSION  5 

i  °f  i 

Rome  Air  Devebpment  Center  «j 

n  RAVC  plant  and  execute t  retearch,  development,  tett  and  \ 

*•  t elected  acquititi.on  programt  in  tupport  of  Command,  Control  £ 

6  Communicationt  and  Intelligence  (C3I)  activiiiet.  Technical  « 

and  engineering  6  upport  within  or  eat  o  f  technical  competence  C 
it  provided  to  ESV  Program  Officet  (POt)  and  o their.  BSD  > 

jj  elementt.  The  principal  technical  mittion  or  eat  are  % 

?  communicationt ,  electromagnetic  guidance  and  control,  tar-  <■ 

5  veillance  of  ground  and  aerotpace  obiectt,  intelligence  data  \ 

collecti on  and  handling,  information  tyttem  technology,  s. 

6  ionotpheric  propagation,  tolid  ttate  tciencet,  microwave 
Jb  phytict  and  electronic  reliability,  maintainability  and 
&  compatibility. 


